From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 15EA5386C590 for ; Thu, 30 Jun 2022 18:43:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15EA5386C590 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f49.google.com with SMTP id v9so13003383wrp.7 for ; Thu, 30 Jun 2022 11:43:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=pLDX3hmPCWl4PdYfpVqLRkYryjPLrdd+KjTFHXaYaro=; b=jUDVuq23YDIIsINFg9iF34Lup+zuUmzpGam+nkx8kEwJNCBXyYqleZV+ObhtA/dwjG BnVheYV7S5Hfan8W22pmbf+UMxn/tdDgskY1BUGYTKZWSogE/zDy8Mdr/HsUUqU8lZ09 1iE0v1DKrqr7b3syz6Uc8AW8Z/Ltja642KSELvKOT0fPVeEgmrO7JTknnJZYb3fZEnM7 xbAUP/t5OTDGjt43tZBbUl4Mn6rcvUFYPWc4HR8tNiODC7Qm1+fPUOEEdG/EObRNvzD6 COK84Q0XDhNobqIRn/obL+Jbxdr8SjyuSO3ehqz3LZrRHtBWeoyQjt3i1Tdq2g5w/O+k 54Qg== X-Gm-Message-State: AJIora9jgGmkK1+4iv0F3Y7USaCXLBrkqfOjwanKiLsmYD7Sf+BSgQ1U /zH9VTOMEQsXqXnC5+mmSku39Q4A6iQ= X-Google-Smtp-Source: AGRyM1t21VWiAzWVGLZOAZ1YXhKB+9P3em1WGZ7/gNi2wveRdbEKzl2uYskX73zR8d1RHPmx70dz9Q== X-Received: by 2002:adf:e28a:0:b0:210:b31:722 with SMTP id v10-20020adfe28a000000b002100b310722mr9882925wri.65.1656614585679; Thu, 30 Jun 2022 11:43:05 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id c8-20020a05600c0a4800b003a02f957245sm92857wmq.26.2022.06.30.11.43.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jun 2022 11:43:04 -0700 (PDT) Message-ID: <39b8b2c1-0aee-e830-92bb-e37256b183f6@palves.net> Date: Thu, 30 Jun 2022 19:43:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Formatting/indentation of lambdas (Re: [PATCH 2/3] gdb/varobj: Fix use after free in varobj) Content-Language: en-US To: Andrew Burgess , Lancelot SIX via Gdb-patches Cc: lsix@lancelotsix.com, Lancelot SIX References: <20220617101024.2830260-1-lancelot.six@amd.com> <20220617101024.2830260-3-lancelot.six@amd.com> <87v8szclvu.fsf@redhat.com> From: Pedro Alves In-Reply-To: <87v8szclvu.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 18:43:08 -0000 On 2022-06-17 17:09, Andrew Burgess via Gdb-patches wrote: >> /* Update the internal variables and value history when OBJFILE is >> discarded; we must copy the types out of the objfile. New global types >> will be created for every convenience variable which currently points to >> @@ -2617,6 +2633,11 @@ preserve_values (struct objfile *objfile) >> for (var = internalvars; var; var = var->next) >> preserve_one_internalvar (var, objfile, copied_types.get ()); >> >> + /* For the remaining varobj, check that none has type owned by OBJFILE. */ >> + all_root_varobjs ([&copied_types, objfile](struct varobj *varobj) >> + { preserve_one_varobj (varobj, objfile, >> + copied_types.get ()); }); >> + > > I think the formatting here is a little off. Looking through other > examples in GDB I think the most common layout would be: > > all_root_varobjs ([&copied_types, objfile] (struct varobj *varobj) > { > preserve_one_varobj (varobj, objfile, > copied_types.get ()); > }); For for-each-like functions that take a lambda, I like to indent the body of lambda as-if you really had a for loop. Like: all_root_varobjs ([&copied_types, objfile] (struct varobj *varobj) { preserve_one_varobj (varobj, objfile, copied_types.get ()); }); which looks similar to what you'd have if you had a real for, like: for (varobj *varobj: root_varobjs ()) { preserve_one_varobj (varobj, objfile, copied_types.get ()); } I'll give you at least a couple existing examples. E.g., in gdb/linux-nat.c: /* No use iterating unless we're resuming other threads. */ if (scope_ptid != lp->ptid) iterate_over_lwps (scope_ptid, [=] (struct lwp_info *info) { return linux_nat_resume_callback (info, lp); }); and in gdbserver, any for_each_thread call, like: for_each_thread ([&] (thread_info *thread) { handle_qxfer_threads_worker (thread, buffer); }); I've noticed that LLVM also uses this style. It is nicely described here: https://llvm.org/docs/CodingStandards.html#format-lambdas-like-blocks-of-code For the case where we have multiple lambdas in a single function call, or when the lambda isn't the last argument, I agree with LLVM, adjusted for GNU style. As in, indent like other parameters. An example for this is expand_symtabs_matching, which takes several gdb::function_view arguments. Here's an example call: /* Look through the partial symtabs for all symbols which begin by matching SYM_TEXT. Expand all CUs that you find to the list. */ expand_symtabs_matching (NULL, lookup_name, NULL, [&] (compunit_symtab *symtab) /* expansion notify */ { add_symtab_completions (symtab, tracker, mode, lookup_name, sym_text, word, code); return true; }, SEARCH_GLOBAL_BLOCK | SEARCH_STATIC_BLOCK, ALL_DOMAIN); I suggest we follow these conventions, and document it in the internals manual, so we have a url we can point to the next time this comes up (it's not the first time).