From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp24.apple.com (rn-mailsvcp-ppex-lapp24.apple.com [17.179.253.38]) by mx.groups.io with SMTP id smtpd.web08.6930.1636426059789683219 for ; Mon, 08 Nov 2021 18:47:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=K09cpm1s; spf=pass (domain: apple.com, ip: 17.179.253.38, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp24.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp24.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 1A92bp0M000388; Mon, 8 Nov 2021 18:47:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=cOH0dFo0mTBzXX1g1Sy+xdbsNgIwY5w2tVrZKhigu5I=; b=K09cpm1s+IDCEA/LP/9AdPMnC8aCkmIu/Y3gN1T2zj8uFxvhz88nSiqgWFasolE4dvws ElpFCISTXlg94neGHOivyk7UTQ+2uGDBlfPFUAwBtiBYieYHFy1UvutaqbPK+Yd9q/26 BV1t20QcLZETzSAjOSedAT4kXfb2Qz4lpCW+o6/fbwO7Ry6rk9+Qwz7JXkHM7B674drS r8TyO1rzSojOk0Hubbs5t9pDN6SwvGdHQPGqaCqFWeLbuOlAH6LJ2uus62xwuxUk/LZy u5C5OzCnPSCc28KzRVsHyKO7WMIYh30Xnd7KjcXAwCXODXH7D0lX0VXz59ERHQ9qEFZo +A== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp24.rno.apple.com with ESMTP id 3c5qaavtr0-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 08 Nov 2021 18:47:37 -0800 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2A003BNAF97P40@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 08 Nov 2021 18:47:33 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2A00900ABFWC00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 08 Nov 2021 18:47:33 -0800 (PST) X-V-A: X-V-T-CD: da3a4df698400084da27c6ab403bcb35 X-V-E-CD: 574fda742400e238a02c5048d028c5dd X-V-R-CD: b4e96f8f3d52136df210f2e6a101920e X-V-CD: 0 X-V-ID: e3f2f7a7-f36a-4ba9-8719-19ab48453728 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.790 definitions=2021-11-08_07:2021-11-08,2021-11-08 signatures=0 Received: from smtpclient.apple (unknown [17.235.8.214]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2A00ZA6ADUES00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 08 Nov 2021 18:46:43 -0800 (PST) From: "Andrew Fish" Message-id: <07F39C4E-DA8E-4650-A48B-66DA2E08314B@apple.com> MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2? Date: Mon, 08 Nov 2021 18:46:42 -0800 In-reply-to: Cc: "devel@edk2.groups.io" , =?utf-8?Q?Marvin_H=C3=A4user?= , Michael Kubacki , Leif Lindholm , "mikuback@linux.microsoft.com" , "rebecca@nuviainc.com" , Bret Barkelew To: Mike Kinney References: <07a6ecff-f7bf-083a-f24d-246ca6c7988b@nuviainc.com> <2679bfa3-b4ec-d8e9-7e56-54ebe42d9001@posteo.de> <9fe0f984-db9d-9aec-0b44-5d30791a2855@linux.microsoft.com> <20211007104813.wa4rmfsqgcpvnzwt@leviathan> <07d5c8bc-40b2-4e99-3b3d-4c8ac4e14220@posteo.de> <438B4D66-2CFB-45E3-AF75-42342F0B1E67@apple.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.790 definitions=2021-11-08_07:2021-11-08,2021-11-08 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_E9DFCCDA-B018-4F63-B54A-60D212424E6F" --Apple-Mail=_E9DFCCDA-B018-4F63-B54A-60D212424E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 8, 2021, at 5:13 PM, Kinney, Michael D wrote: >=20 > HI Andrew, > =20 > Great feedback. > =20 > What your preferred way to install a tool like this? If we collect that = data from the community, we can make sure the pipeline generates the right = type of installers. > =20 I could not figure out how to download an installer from the links.=20 If I go to http://uncrustify.sourceforge.net I see https://sourceforge.net/projects/uncrustify/files/ and a button to download binaries= . Not ideal that it is only for Windows but at least the workflow was obvio= us. Looks like I need to build my own version for macOS, not ideal but I ca= n at least figure that out.=20 Worst case we can have a Tianocore.org page to desc= ribe a simple recipe to install the tool. With step by step instructions so= me one can just type in without thinking too much.=20 Thanks, Andrew Fish > Thanks, > =20 > Mike > =20 > From: Andrew Fish =20 > Sent: Monday, November 8, 2021 5:09 PM > To: devel@edk2.groups.io; Kinney, Michael D > Cc: Marvin H=C3=A4user ; Michael Kubacki ; Leif Lindholm ; mikuback@linux.micr= osoft.com; rebecca@nuviainc.com; Bret Barkelew > Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2= ? > =20 > MIke, > =20 > I could not figure out how to download uncrustify tool from the provided = link. 99% of the people are just going to want to install the tool, not be = a developer of the fork. We should have some simple instructions on how to = download the tool.=20 > =20 > The link points to something git web view looking Azure DevOps page and t= alks about this Nuget thing I know nothing about. I ran out of time and had= to give up trying to download the tool.=20 > =20 > Thanks, > =20 > Andrew Fish >=20 >=20 > On Nov 8, 2021, at 4:23 PM, Michael D Kinney > wrote: > =20 > Hello, > =20 > Good information in this thread on code style. > =20 > Some of the topics apply to uncrustify and some are out of scope for what= uncrustify can fix on its own. > =20 > I would like to focus on a date to convert all source code in edk2 repo u= sing the uncrustify tool and to capture the other code style topics into th= eir own thread andbugzillas. > =20 > I would like to propose a conversion date for uncrustify immediately afte= r the edk2-stable202111 release on 2021-11-26. > =20 > I have been working with Michael Kubacki on a build comparison tool that = verifies that the build generate the same obj/lib/dll/efi/fv/fd files befor= e and after the uncrustify changes. We would run and publish the results f= rom this tool before committing the changes. > =20 > We need TianoCore community approval of the following: > =20 > Approve format of C source generated by the uncrustify. > Approve uncrustify changes right after edk2-stable-202111 release.=20 > Extend code freeze until these changes are committed. > Require use of uncrustify tool before submitting patch review emails or P= Rs. > The required version would be a formally released version from the fork = maintained by Michael Kubacki until the changes can be upstreamed. > https://dev.azure.com/projectmu/Uncrustify > Add EDK II CI check to verify that all PRs submitted exactly match uncrus= tified version. Reject PRs that do not match exactly. > Implement a git hook available that would automatically run uncristufy be= fore committing changes to a local branch of an edk2 repo. > =20 > Thanks, > =20 > Mike > =20 > From: Andrew Fish >=20 > Sent: Thursday, October 7, 2021 2:09 PM > To: Marvin H=C3=A4user > > Cc: edk2-devel-groups-io >; Kinney, Michael D >; Leif Lindholm >= ; mikuback@linux.microsoft.com ; rebec= ca@nuviainc.com ; Michael Kubacki >; Bret Barkelew <= Bret.Barkelew@microsoft.com > > Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2= ? > =20 > =20 >=20 >=20 >=20 > On Oct 7, 2021, at 1:43 PM, Marvin H=C3=A4user > wrote: > =20 > Hey Mike, > Hey Andrew, >=20 > I'll just reply to both mails at once :) >=20 > On 07/10/2021 19:36, Andrew Fish wrote: >=20 >=20 >=20 >=20 >=20 >=20 > On Oct 7, 2021, at 1:19 PM, Michael D Kinney > wrote: >=20 > Hi Marvin, >=20 > Some comments below. >=20 > Mike >=20 >=20 >=20 > -----Original Message----- > From:devel@edk2.groups.io > On Behalf Of Marvin H=C3=A4user > Sent: Thursday, October 7, 2021 11:31 AM > To: Leif Lindholm >;devel@ed= k2.groups.io ;mikuback@linux.microsoft.com > Cc:rebecca@nuviainc.com ; Michael Kubacki >; Bret = Barkelew >= ; > Kinney, Michael D > > Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2= ? >=20 > Good day, >=20 > +1, but while you're at it, can we have arguments not align to the > function name... >=20 > Status =3D Test ( > a > ); >=20 > ... but to the next natural indentation level? >=20 > Status =3D Test ( > a > ); >=20 > Basically no IDE I have seen supports EDK II's style, and I wouldn't be > keen on writing known-broken style to then rely on Uncrustify to fix it. >=20 > I also have heard some controversy regarding casts off-list, where some > prefer no spaces after casts to stress the evaluation order, and some > prefer spaces to have clearer visuals (as a cast *ideally* would be > something rare that requires good justification). Just throwing that out > there. >=20 >=20 > For things unrelated to autoformat (so semi-offtopic) but still relevant > to the coding spec: >=20 > 1. Allow STATIC functions (if the debugging concerns are still relevant, > there could be another level of indirection, like RELEASE_STATIC)? >=20 > Debugging concerns are no longer relevant. The suggestion in the BZ belo= w > is to remove the STATIC macro and allow EDK II sources to add 'static' > to any functions it makes sense to use on. >=20 > https://bugzilla.tianocore.org/show_bug.cgi?id=3D1766 >=20 > Thanks! I'd keep STATIC actually just for the sake of not doing no-op cha= nges that do not really do anything and for consistency with CONST, but wha= tever works really. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 2. Allow variable assignments on definition (basically non-static CONST > variables are banned...)? >=20 > Are referring to use of pre-initialized CONST variables declared within > a function? I think Bret brought this topic up when implementing some > unit tests and the suggestion to pass ECCC was to promote them to > pre-initialized CONST global variables. >=20 > Yes. >=20 >=20 >=20 >=20 > The challenges we have seen in the past with pre-initialized variables wi= thin > a function is that they can cause compilers to inject use of memcpy() cal= ls, > especially if the variable being initialized on the stack is a structure. > These cause build breaks today. >=20 > This issue is independent of CONST. I=E2=80=99m not sure a coding style t= ool is smart enough to catch this generically? You need an understanding of= C types to know if the local variable assignment is going to trigger a mem= cpy(). >=20 > What I=E2=80=99ve seen in the real world is the firmware compiles with -O= s or LTO to fit int he ROM for DEBUG and RELEASE, and the optimizer optimiz= es away the call to memcpy. Then if you try to build NOOPT (or over ride th= e compiler flags on an individual driver/lib) you fail to link as only the = NOOPT build injects the memcpy. >=20 > +1 >=20 >=20 >=20 >=20 > Thus I think the best way to enforce this rule is to compile a project NO= OPT. I=E2=80=99m trying to remember are there flags to built to tell it to = compile and skip the FD construction? Maybe we should advocate platforms ad= d a NOOPT build target that just compiles the code, but does not create the= FD? >=20 > I know there were stability concerns with intrinsics in the past, but mem= cpy() is in the standard, and the rest remained stable to my knowledge. May= be it's time to fix the issues at the root? Works for us: > https://github.com/acidanthera/OpenCorePkg/tree/master/Library/OcCompiler= IntrinsicsLib > =20 > Marvin, > =20 > Good point. This would make the rule moot. So maybe just removing the req= uirement would be the easiest long term fix.=20 > =20 > Other embedded projects I know of do this too, and as you point out the c= ompilers keep these APIs standard for folks the provide their own runtimes. > =20 > Thanks, > =20 > Andrew Fish >=20 >=20 >=20 > Best regards, > Marvin >=20 >=20 >=20 >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 3. Allow variable declarations at any scope (I had some nasty shadowing > bugs before, probably prohibit shadowing with warnings)? >=20 > By shadowing do you mean the declaration of the same variable name in > multiple scoped within the same function? >=20 >=20 >=20 >=20 > 4. Require that exactly all function declarations and all function > definitions with no prior declaration must be documented (first > direction is enforcing docs, second is prohibiting doc duplication, I've > seen them go out-of-sync plenty of times)? >=20 > I agree that this can reduce duplication and sync issues. The uncrustify > tool being discussed here could not help clean this up or enforce this > type of rule. It is a good topic, but may need to be split out into its > own thread. >=20 >=20 >=20 >=20 > The latter bunch would not require any autoformat rules or reformatation > of existing code, but would be target only new submissions in my > opinion. Thoughts? >=20 >=20 > Thanks for your efforts! >=20 > Best regards, > Marvin >=20 >=20 > Am 07.10.2021 um 12:48 schrieb Leif Lindholm: >=20 >=20 > Hi Michael, >=20 > Apologies, I've owed you a response (promised off-list) for a while > now. >=20 > First, let me say I hugely appreciate this effort. Apart from aligning > the codebase(s), this will reduce manual reviewing effort > substantially, as well as cutting down on number of rework cycles for > developers. >=20 > Looking at the changes to (well, the comments in) uncrustify, this > seems to be constrained to: > - Newline after '(' for multi-line function calls. > - Dealing with "(("/"))" for DEBUG macros. > - Function pointer typedefs: > - typedef\nEFIAPI > - closing parentheses indentation >=20 > I don't think I've made any secret over the years that I am not a > massive fan of the EDK2 coding style in general. So I think for any > of its quirks that are substantial enough that they require not just > custom configuration but actual new function added to existing code > conformance tools, this would be an excellent point to sanitise the > coding style instead. >=20 > Taking these in order: >=20 > Newline after '(' > ----------------- > I think we already reached a level of flexibility around this, where > we don't actually enforce this (or single argument per > line). Personally, I'd be happy to update the coding style as > required instead. >=20 > DEBUG macro parentheses > ----------------------- > How does uncrustify treat DEBUG macros without this modification? > Do we start getting everything turned into multi-level indented > multi-line statements without this change? >=20 > Function pointer typedefs: > -------------------------- > I don't see that function pointer typedefs need to rigidly follow the > same pattern as the declaration of functions implementing them. Could > we update the coding style (if needed) instead? >=20 > Best Regards, >=20 > Leif >=20 > On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote: >=20 >=20 > The edk2 branch was created here: > https://github.com/makubacki/edk2/tree/uncrustify_poc_2 >=20 > We have a Project Mu fork with custom changes to the Uncrustify tool to h= elp > comply with EDK II formatting here: > https://dev.azure.com/projectmu/_git/Uncrustify >=20 > The latest information about the status and how to experiment with the > configuration file and the tool are in that fork: > https://dev.azure.com/projectmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/= Project-Mu-(EDK-II)-Fork-Readme >=20 >=20 >=20 > That said, I have also finished a CI plugin to run Uncrustify that should= be > ready soon to initially deploy in Project Mu. Before doing so, I am tryin= g > to settle on an initial configuration file that less strictly but more > reliably formats the code than in the examples in those branches. For > example, remove heuristics that when run against the same set of code > multiple times can produce different results. An example would be a rule > that reformats code because it exceeds a specified column width on one ru= n > but on the next run that reformatted code triggers a different rule to > further align the code and so on. At least initially, some rules might be > tweaked in a more conservative approach that can be tightened in the futu= re. > Once this configuration file is ready, we will baseline Project Mu code a= s > an example and turn on the plugin. The CI plugin runs Uncrustify against > modified files and if there's any changes, indicating a formatting > deviation, the diff chunks are saved in a log so they can be viewed as a > build artifact. >=20 > I am making progress on the updated config file and I should be able to p= ost > a "uncrustify_poc_3" branch soon with the results. >=20 > Regarding indentation, Marvin is right that Uncrustify cannot support edk= 2 > indentation style out-of-box. Some changes are made in that fork to handl= e > the formatting. At this point, it can handle the indentation in the cases > I've seen. Uncrustify does potentially give us the ability to massively > deploy changes across the codebase in case a decision were made to change > the style. >=20 > Thanks, > Michael >=20 > On 8/16/2021 3:39 PM, Marvin H=C3=A4user wrote: >=20 >=20 > Hey Rebecca, >=20 > I think even Uncrustify has issues with the EDK II indentation style. > You might want to check the UEFI Talkbox Discord server, I had a brief > chat with Michael about it there. I don't think realistically any tool > supports EDK II's indentation style however, so I'd propose it is > changed. This could be for new submissions only, or actually the entire > codebase could be reformatted at once with a good tool setup. While this > screws with git blame, the (to my understanding) decided on CRLF -> LF > change does that anyway, so at least two evils could be dealt with in > one go really. >=20 > Best regards, > Marvin >=20 > On 16/08/2021 21:34, Rebecca Cran wrote: >=20 >=20 >=20 > cc devel@ . >=20 > On 8/16/21 1:33 PM, Rebecca Cran wrote: >=20 >=20 >=20 > I noticed a message on Twitter about an idea of using Uncrustify > for EDK2 instead of the ECC tool, and came across https://www.mail- > archive.com/search?l=3Ddevel@edk2.groups.io&q=3Dsubject:%22Re%5C%3A+%5C%5= Bedk2%5C- > devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=3Dnewe= st&f=3D1 >=20 >=20 > . >=20 > I was wondering if there's been any progress on it that I could > check out? >=20 >=20 > Michael Kubacki: in that message, you said: >=20 > "I'm planning to put up a branch that we can use as a reference > for a conversation around uncrustify in the next couple of > weeks." >=20 >=20 > Did you end up creating that branch, and if so could you provide > a link to it please? >=20 >=20 > -- > Rebecca Cran >=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 --Apple-Mail=_E9DFCCDA-B018-4F63-B54A-60D212424E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 8, 202= 1, at 5:13 PM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:

HI Andrew,=
 
Great feedback.
 
What your preferred way to install= a tool like this?  If we collect that data from the community, we can = make sure the pipeline generates the right type of installers.
 = ;

I could not figure out how to download an installer from the links. <= /div>

If I go to http://uncrustify.sourceforge.net&nbs= p;I see https://sourceforge.net/projects/uncrustify/files/ and= a button to download binaries. Not ideal that it is only for Windows but a= t least the workflow was obvious. Looks like I need to build my own version= for macOS, not ideal but I can at least figure that out. 
<= br class=3D"">
Worst case we can have a Tianocore.org page to describe a simple recipe = to install the tool. With step by step instructions some one can just type = in without thinking too much. 

Tha= nks,

Andrew Fish

Thanks,
 
Mike
 
From: Andrew Fish <afish@apple.com> 
Sent: Monday, November 8, 2021 5:09 PM
To: devel@edk2.groups.io; Kinney, M= ichael D <micha= el.d.kinney@intel.com>
Cc: Marvin H=C3=A4user <mhaeuser@posteo.de>; Michael K= ubacki <Mich= ael.Kubacki@microsoft.com>; Leif Lindholm <leif@nuviainc.com>; mikuback@linux.microsoft.com; rebecca@nuviainc.com; Br= et Barkelew <B= ret.Barkelew@microsoft.com>
Subject:=  Re: [edk2-devel] Progres= s on getting Uncrustify working for EDK2?
 
MIke,
=
 
I could not figure out = how to download uncrustify tool from the provided link. 99% of the people a= re just going to want to install the tool, not be a developer of the fork. = We should have some simple instructions on how to download the tool. <= o:p class=3D"">
 
The link points to something git web view = looking Azure DevOps page and talks about this Nuget thing I know nothing a= bout. I ran out of time and had to give up trying to download the tool.&nbs= p;
<= span class=3D""> 
Thanks,<= /div>
=  
Andrew Fish


On Nov 8, 2021, a= t 4:23 PM, Michael D Kinney <michael.= d.kinney@intel.com> wrote:
<= div style=3D"margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif= ;" class=3D""> 
Hello,
 
Good information in this thread on code style.
 
<= div style=3D"margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif= ;" class=3D"">Some of the topics apply to uncrustify<= span class=3D"apple-converted-space"> and some are out of scope= for what uncrustify can fix on its own.
 
=
I would like to focus= on a date to convert all source code in edk2 repo using the uncrustify tool and to capture the= other code style topics into their own thread andbu= gzillas.
 
I would like to propose a = conversion date for uncrustify&n= bsp;immediately after the edk2-stable202111 release on 2021-11-26.
 
=
I have been working with Michael Kubacki on= a build comparison tool that verifies that the build generate the same obj= /lib/dll/efi/fv/fd files before and after the uncrustify=  changes.  We would run and publish th= e results from this tool before committing the changes.
 =
We need TianoCore&= nbsp;community approval of the following:
 
  1. <= span class=3D"">Approve format of C source generated by the uncrustify= .
  2. Approve uncrustify <= /span>changes right after edk2-stable-202111 release. =
    1. Extend code freeze until these changes are committed.
  1. Require use of&nbs= p;uncrustify tool before submitting patch review emails or PRs.=
    1. The required version would be a formally rel= eased version  from = the fork maintained by Michael Kubacki until the changes can be upstreamed.
    2. https://dev.azure.com/projectmu/Uncrustify
  1. Add EDK II CI check to verify that all PRs submi= tted exactly match uncrustified&= nbsp;version.  Reject PRs that do not match exactly.
    2. Implement a git hook available= that would automatically run uncristufy before committing changes to a local branch of an edk2= repo.
 
Thanks,<= /div>
 
Mike
From: Andrew Fish <afish@apple.com> 
Sent: Thursday, October 7, 2021 2:09 PMTo:&nb= sp;Marvin H=C3=A4user <mhaeuser@posteo.de>
= Cc: edk= 2-devel-groups-io <devel@edk2.groups.io>; Kinney, Michael D &l= t;michael.d.kinney@intel.com>; Leif Lindholm <leif@nuviainc.= com>; m= ikuback@linux.microsoft.com; rebecca@nuviainc.com; Michael Kubacki <Michae= l.Kubacki@microsoft.com>; Bret Barkelew <Bret.Barkelew@= microsoft.com>
Subject: Re: [edk2-devel] Progress on g= etting Uncrustify working for EDK2?
 
 


On Oct 7, 2021, at 1:43 PM, Marvin H= =C3=A4user <mhaeuser@posteo.de> wrote:
 =
Hey Mike,
Hey Andrew,

I'll just reply to both mails at once :)

On 07/10/2021 19:36, Andrew Fish wrote:






=
On Oct 7, 2021, at 1:19 PM, Michael D K= inney <michael.d.kinney@intel.com> wrote:
=
Hi Marvin,

Some comments below.=

Mike



<= /div>
-----Original Message-----
From:devel@edk2.groups.io<devel@edk2.groups.io> = On Behalf Of Marvin H=C3=A4user
Sent: Thursday, October 7, 20= 21 11:31 AM
To: Leif Lindholm <<= span style=3D"color: purple;" class=3D"">leif@nuviainc.com>;<= a href=3D"mailto:devel@edk2.groups.io" style=3D"color: purple; text-decorat= ion: underline;" class=3D"">devel= @edk2.groups.io;mikuback@linux.microsoft.com
Cc:rebecca@nuviainc.com; Michael Kubacki <Michael.= Kubacki@microsoft.com>; Bret Barkelew <Bret.Barkelew@mi= crosoft.com>;
Kinney, Michael D <michael.d= .kinney@intel.com>
Subject: Re: [edk2-devel] Pr= ogress on getting Uncrustify working for EDK2?

Good day,

+1, but while you're at it, can we = have arguments not align to the
function name...

  Status =3D Test (
  &n= bsp;          a
           &nb= sp; );

... but to the next natural indent= ation level?

  Status =3D Test (
    a
    = );

Basically no IDE I have seen supports EDK I= I's style, and I wouldn't be
keen on writing known-broken sty= le to then rely on Uncrustify to fix it.

I als= o have heard some controversy regarding casts off-list, where some
prefer no spaces after casts to stress the evaluation order, and some=
prefer spaces to have clearer visuals (as a cast *ideally* w= ould be
something rare that requires good justification). Jus= t throwing that out
there.


For things unrelated to autoformat (so semi-offtopic) but still r= elevant
to the coding spec:

1. A= llow STATIC functions (if the debugging concerns are still relevant,
there could be another level of indirection, like RELEASE_STATIC)?<= /span>

Debugging concerns are = no longer relevant.  The suggestion in the BZ below
is t= o remove the STATIC macro and allow EDK II sources to add 'static'
to any functions it makes sense to use on.

https://bugzilla.tianocore.org/show_bug.cgi?id=3D= 1766
<= /div>

Thanks! I'd keep STATIC actually just for the sake of not doing no-= op changes that do not really do anything and for consistency with CONST, b= ut whatever works really.



=




2. Allow variable assignments on definition (= basically non-static CONST
variables are banned...)?

Are referring to use of pre-ini= tialized CONST variables declared within
a function?  I = think Bret brought this topic up when implementing some
unit = tests and the suggestion to pass ECCC was to promote them to
= pre-initialized CONST global variables.

Yes.



<= /div>

The challenges we have s= een in the past with pre-initialized variables within
a funct= ion is that they can cause compilers to inject use of memcpy() calls,
especially if the variable being initialized on the stack is a str= ucture.
These cause build breaks today.

This issue is independent of CONST. I=E2=80= =99m not sure a coding style tool is smart enough to catch this generically= ? You need an understanding of C types to know if the local variable assign= ment is going to trigger a memcpy().

What I=E2= =80=99ve seen in the real world is the firmware compiles with -Os or LTO to= fit int he ROM for DEBUG and RELEASE, and the optimizer optimizes away the= call to memcpy. Then if you try to build NOOPT (or over ride the compiler = flags on an individual driver/lib) you fail to link as only the NOOPT build= injects the memcpy.

+1=




Thus I think the best way to enforce this rule is to c= ompile a project NOOPT. I=E2=80=99m trying to remember are there flags to b= uilt to tell it to compile and skip the FD construction? Maybe we should ad= vocate platforms add a NOOPT build target that just compiles the code, but = does not create the FD?


I know there were stability concerns with intrinsics in the past, but memc= py() is in the standard, and the rest remained stable to my knowledge. Mayb= e it's time to fix the issues at the root? Works for us:
https://github.com/acidanthera/OpenCoreP= kg/tree/master/Library/OcCompilerIntrinsicsLib

<= span class=3D""> 
Marvin,
 
Good po= int. This would make the rule moot. So maybe just removing the requirement = would be the easiest long term fix. 
 
Other embedded projects I know = of do this too, and as you point out the compilers keep these APIs standard= for folks the provide their own runtimes.
 
Thanks,<= /span>
 
Andrew Fish



Best re= gards,
Marvin



Thanks,

Andrew Fish







3. Allow variable declarations at any scope = (I had some nasty shadowing
bugs before, probably prohibit sh= adowing with warnings)?

By shadowing do you mean the declaration of the same variable name in
multiple scoped within the same function?




4. R= equire that exactly all function declarations and all function
definitions with no prior declaration must be documented (first
direction is enforcing docs, second is prohibiting doc duplication, I= 've
seen them go out-of-sync plenty of times)?

I agree that this can reduce duplic= ation and sync issues.  The uncrustify
tool being discus= sed here could not help clean this up or enforce this
type of= rule.  It is a good topic, but may need to be split out into its
own thread.




The latter bunch would not require= any autoformat rules or reformatation
of existing code, but = would be target only new submissions in my
opinion. Thoughts?=


Thanks for your efforts!

Best regards,
Marvin

Am 07.10.2021 um 12:48 schrieb Leif Lindholm:

Hi Michael,<= br class=3D"">
Apologies, I've owed you a response (promised = off-list) for a while
now.

First= , let me say I hugely appreciate this effort. Apart from aligning
the codebase(s), this will reduce manual reviewing effort
substantially, as well as cutting down on number of rework cycles fordevelopers.

Looking at the changes= to (well, the comments in) uncrustify, this
seems to be cons= trained to:
- Newline after '(' for multi-line function calls= .
- Dealing with "(("/"))" for DEBUG macros.
- = Function pointer typedefs:
  - typedef\nEFIAPI
  - closing parentheses indentation

I don't think I've made any secret over the years that I am not a=
massive fan of the EDK2 coding style in general. So I think = for any
of its quirks that are substantial enough that they r= equire not just
custom configuration but actual new function = added to existing code
conformance tools, this would be an ex= cellent point to sanitise the
coding style instead.

Taking these in order:

Ne= wline after '('
-----------------
I think we al= ready reached a level of flexibility around this, where
we do= n't actually enforce this (or single argument per
line). Pers= onally, I'd be happy to update the coding style as
required i= nstead.

DEBUG macro parentheses
= -----------------------
How does uncrustify treat DEBUG macro= s without this modification?
Do we start getting everything t= urned into multi-level indented
multi-line statements without= this change?

Function pointer typedefs:
--------------------------
I don't see that function= pointer typedefs need to rigidly follow the
same pattern as = the declaration of functions implementing them. Could
we upda= te the coding style (if needed) instead?

Best = Regards,

Leif

On = Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wrote:
<= br class=3D"">
=
The edk2 branch was create= d here:
https://github.com/makuback= i/edk2/tree/uncrustify_poc_2

We hav= e a Project Mu fork with custom changes to the Uncrustify tool to help
comply with EDK II formatting here:
https://dev.azure.com/projectmu/_git/Uncrustify
<= br class=3D"">The latest information about the status and how to experiment= with the
configuration file and the tool are in that fork:
https://dev.azure.com/proje= ctmu/Uncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Read= me


That said, I have also finished a CI plugin to run Uncrustify = that should be
ready soon to initially deploy in Project Mu. = Before doing so, I am trying
to settle on an initial configur= ation file that less strictly but more
reliably formats the c= ode than in the examples in those branches. For
example, remo= ve heuristics that when run against the same set of code
mult= iple times can produce different results. An example would be a rule
that reformats code because it exceeds a specified column width on = one run
but on the next run that reformatted code triggers a = different rule to
further align the code and so on. At least = initially, some rules might be
tweaked in a more conservative= approach that can be tightened in the future.
Once this conf= iguration file is ready, we will baseline Project Mu code as
= an example and turn on the plugin. The CI plugin runs Uncrustify againstmodified files and if there's any changes, indicating a formatt= ing
deviation, the diff chunks are saved in a log so they can= be viewed as a
build artifact.

= I am making progress on the updated config file and I should be able to pos= t
a "uncrustify_poc_3" branch soon with the results.

Regarding indentation, Marvin is right that Uncrustify= cannot support edk2
indentation style out-of-box. Some chang= es are made in that fork to handle
the formatting. At this po= int, it can handle the indentation in the cases
I've seen. Un= crustify does potentially give us the ability to massively
de= ploy changes across the codebase in case a decision were made to change
the style.

Thanks,
Mi= chael

On 8/16/2021 3:39 PM, Marvin H=C3=A4user= wrote:


Hey= Rebecca,

I think even Uncrustify has issues w= ith the EDK II indentation style.
You might want to check the= UEFI Talkbox Discord server, I had a brief
chat with Michael= about it there. I don't think realistically any tool
support= s EDK II's indentation style however, so I'd propose it is
ch= anged. This could be for new submissions only, or actually the entire
codebase could be reformatted at once with a good tool setup. Whil= e this
screws with git blame, the (to my understanding) decid= ed on CRLF -> LF
change does that anyway, so at least two = evils could be dealt with in
one go really.
Best regards,
Marvin

On 16/08/2021 21:34, Rebecca Cran wrote:



cc devel@ .
On 8/16/21 1:33 PM, Rebecca Cran wrote:


<= /div>

I noticed a message= on Twitter about an idea of using Uncrustify
for EDK2 instea= d of the ECC tool, and came across&nb= sp;htt= ps://www.mail-
archive.com/search?l=3Ddevel@edk2.groups.io&= q=3Dsubject:%22Re%5C%3A+%5C%5Bedk2%5C-
devel%5C%5D= +TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=3Dnewest&f= =3D1


.

I was wondering if there's been any progress on it that I could
check out?


Michael Kub= acki: in that message, you said:

"I'm planning= to put up a branch that we can use as a reference
for a conv= ersation around uncrustify in the next couple of
weeks."


Did you end up creating that branch= , and if so could you provide
a link to it please?


--
Rebecca Cran

&nbs= p;
















<= o:p class=3D"">




<= /div>
&nb= sp;

--Apple-Mail=_E9DFCCDA-B018-4F63-B54A-60D212424E6F--