From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp45.apple.com (rn-mailsvcp-ppex-lapp45.apple.com [17.179.253.49]) by mx.groups.io with SMTP id smtpd.web10.92.1633628177204261423 for ; Thu, 07 Oct 2021 10:36:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=sia0CGIa; spf=pass (domain: apple.com, ip: 17.179.253.49, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp45.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp45.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 197HYDld030879; Thu, 7 Oct 2021 10:36:14 -0700 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=hUg6e6Y2aT0XIOMEtPY+JHhlVI4KPIVtkTmuONIwBnA=; b=sia0CGIa2hdulXdiF2IusmdwwxE6bhbzn1dOEPRcLDzo7ipmZrWoSMtEveGlF0ahSA0v gIUgptHD4R4qz0T9qtElC9FNBTEGqHInL6bkCklEaJQWKWgAVnQC2tOZsI2OKN94oI9a L8g+X9skEI9QY/pmcLY5xxeoSs6bWibiADidgk2Ym22jLwkwYZV+JJIbBLp2OqigI5jn 4gWsoOWC1KKoXEsS3Cf0IZK2ti8i2wq7vxj+JnTqys5bJbJDrqVE8Y2AHh5qRGy6HQ4w tQS10nFW3dpbx75zzaXGbHcIinBWb414BShVq++o7dckeFSynW7ltpgJFskhooQD8mKg JQ== Received: from ma-mailsvcp-mta-lapp04.corp.apple.com (ma-mailsvcp-mta-lapp04.corp.apple.com [10.226.18.136]) by rn-mailsvcp-ppex-lapp45.rno.apple.com with ESMTP id 3benqtk9e3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 07 Oct 2021 10:36:14 -0700 Received: from ma-mailsvcp-mmp-lapp04.apple.com (ma-mailsvcp-mmp-lapp04.apple.com [17.32.222.17]) by ma-mailsvcp-mta-lapp04.corp.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R0M004WJBKEB100@ma-mailsvcp-mta-lapp04.corp.apple.com>; Thu, 07 Oct 2021 10:36:14 -0700 (PDT) Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp04.apple.com by ma-mailsvcp-mmp-lapp04.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0R0M00M00B7O8F00@ma-mailsvcp-mmp-lapp04.apple.com>; Thu, 07 Oct 2021 10:36:14 -0700 (PDT) X-Va-A: X-Va-T-CD: 70a38c3f5b1d46c4b8dccb3b011be358 X-Va-E-CD: 574fda742400e238a02c5048d028c5dd X-Va-R-CD: b4e96f8f3d52136df210f2e6a101920e X-Va-CD: 0 X-Va-ID: b1b90a21-48af-460c-8be1-aca9592b07f3 X-V-A: X-V-T-CD: 70a38c3f5b1d46c4b8dccb3b011be358 X-V-E-CD: 574fda742400e238a02c5048d028c5dd X-V-R-CD: b4e96f8f3d52136df210f2e6a101920e X-V-CD: 0 X-V-ID: 2dbc6623-1797-4693-a90a-fc58aac325b2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-03_02:2021-08-02,2021-08-03 signatures=0 Received: from [17.234.148.236] (unknown [17.234.148.236]) by ma-mailsvcp-mmp-lapp04.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0R0M00HE3BK1MH00@ma-mailsvcp-mmp-lapp04.apple.com>; Thu, 07 Oct 2021 10:36:13 -0700 (PDT) From: "Andrew Fish" Message-id: <438B4D66-2CFB-45E3-AF75-42342F0B1E67@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK2? Date: Thu, 07 Oct 2021 13:36:01 -0400 In-reply-to: Cc: "mhaeuser@posteo.de" , Leif Lindholm , "mikuback@linux.microsoft.com" , "rebecca@nuviainc.com" , Michael Kubacki , Bret Barkelew To: edk2-devel-groups-io , 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> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-10-07_03:2021-10-07,2021-10-07 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_69A133B8-10F1-4DBF-97B9-FBC8F5E26E26" --Apple-Mail=_69A133B8-10F1-4DBF-97B9-FBC8F5E26E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 7, 2021, at 1:19 PM, Michael D Kinney = wrote: >=20 > Hi Marvin, >=20 > Some comments below. >=20 > Mike >=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@= edk2.groups.io ; mikuback@linux.microsoft.com = >> Cc: rebecca@nuviainc.com ; Michael Kubacki = >; Bre= t Barkelew >; >> Kinney, Michael D > >> Subject: Re: [edk2-devel] Progress on getting Uncrustify working for EDK= 2? >>=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=20 > 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 >>=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=20 > pre-initialized CONST global variables. >=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. This issue is independent of CONST. I=E2=80=99m not sure a coding style too= l 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 memcp= y().=20 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 NO= OPT build injects the memcpy.=20 Thus I think the best way to enforce this rule is to compile a project NOOP= T. I=E2=80=99m trying to remember are there flags to built to tell it to co= mpile and skip the FD construction? Maybe we should advocate platforms add = a NOOPT build target that just compiles the code, but does not create the F= D? Thanks, Andrew Fish >=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 >> 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 >> 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: >>> 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: >>>> 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 t= o help >>>> 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 >>>> That said, I have also finished a CI plugin to run Uncrustify that sho= uld be >>>> ready soon to initially deploy in Project Mu. Before doing so, I am tr= ying >>>> 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 ru= le >>>> 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 f= uture. >>>> Once this configuration file is ready, we will baseline Project Mu cod= e as >>>> an example and turn on the plugin. The CI plugin runs Uncrustify again= st >>>> 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 t= o post >>>> a "uncrustify_poc_3" branch soon with the results. >>>>=20 >>>> Regarding indentation, Marvin is right that Uncrustify cannot support = edk2 >>>> indentation style out-of-box. Some changes are made in that fork to ha= ndle >>>> the formatting. At this point, it can handle the indentation in the ca= ses >>>> I've seen. Uncrustify does potentially give us the ability to massivel= y >>>> deploy changes across the codebase in case a decision were made to cha= nge >>>> the style. >>>>=20 >>>> Thanks, >>>> Michael >>>>=20 >>>> On 8/16/2021 3:39 PM, Marvin H=C3=A4user wrote: >>>>> 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 brie= f >>>>> chat with Michael about it there. I don't think realistically any too= l >>>>> supports EDK II's indentation style however, so I'd propose it is >>>>> changed. This could be for new submissions only, or actually the enti= re >>>>> codebase could be reformatted at once with a good tool setup. While t= his >>>>> screws with git blame, the (to my understanding) decided on CRLF -> L= F >>>>> 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 >>>>>> cc devel@ . >>>>>>=20 >>>>>> On 8/16/21 1:33 PM, Rebecca Cran wrote: >>>>>>>=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%= 5Bedk2%5C- >> devel%5C%5D+TianoCore+Community+Meeting+Minutes+%5C-+2%5C%2F4%22&o=3Dnew= est&f=3D1 >>>>>>> . >>>>>>>=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 --Apple-Mail=_69A133B8-10F1-4DBF-97B9-FBC8F5E26E26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 7, 202= 1, at 1:19 PM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Hi Marvin,

Some comments below.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Marvin H=C3=A4user=
Sent: Thursday, October 7, 2021 11:31 AM
To: L= eif Lindholm <leif@nuvia= inc.com>; devel@edk2.groups.io; mikuback@linux.microsoft.com
Cc: rebecca@nuviainc.com; Michael Kubacki &l= t;Michael.Kubac= ki@microsoft.com>; Bret Barkelew <Bret.Barkelew@microsoft.com>;
Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-= devel] Progress 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 (
 = ;            a<= br class=3D"">          &= nbsp;  );

... but to the next natura= l indentation level?

  Status =3D Te= st (
    a
  &nbs= p; );

Basically no IDE I have seen suppor= ts EDK II's style, and I wouldn't be
keen on writing known-br= oken style to then rely on Uncrustify to fix it.

I also have heard some controversy regarding casts off-list, where some<= br class=3D"">prefer no spaces after casts to stress the evaluation order, = and some
prefer spaces to have clearer visuals (as a cast *id= eally* would be
something rare that requires good justificati= on). Just throwing that out
there.


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

1. Allow STATIC functions (if the debugging concerns are still releva= nt,
there could be another level of indirection, like RELEASE= _STATIC)?

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

&n= bsp;  https://bugzill= a.tianocore.org/show_bug.cgi?id=3D1766


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

Are referring to use of pre-initia= lized CONST variables declared within
a function?  I think Bret brought this topic up when im= plementing some
unit te= sts and the suggestion to pass ECCC was to promote them to 
pre-initialized CONST global variables.

The = challenges we have seen in the past with pre-initialized variables within
a function is that they = can cause compilers to inject use of memcpy() calls,
especially if the variable being initialized = on the stack is a structure.
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size:= 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; text-align: start; text-indent: 0px; text-transform= : none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: = 0px; text-decoration: none; float: none; display: inline !important;" class= =3D"">These cause build breaks today.

This issue is ind= ependent 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 assignment is going to trigger a memcpy(). 
<= div>
What I=E2=80=99ve seen in the real world is t= he firmware compiles with -Os or LTO to fit int he ROM for DEBUG and RELEAS= E, 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) y= ou fail to link as only the NOOPT build injects the memcpy. 

Thus I think the best way to enforce this rule i= s to compile a project NOOPT. I=E2=80=99m trying to remember are there flag= s to built to tell it to compile and skip the FD construction? Maybe we sho= uld advocate platforms add a NOOPT build target that just compiles the code= , but does not create the FD?

Thanks,

Andrew Fish



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

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


4. Require that exactly all function declarations and = all function
definitions with no prior declaration must be do= cumented (first
direction is enforcing docs, second is prohib= iting doc duplication, I've
seen them go out-of-sync plenty o= f times)?

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.
<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">

Th= e latter bunch would not require any autoformat rules or reformatation
of existing code, but would be target only new submissions in my<= br class=3D"">opinion. Thoughts?


Thanks for your efforts!

Best regards,
Marvin


Am 07.10.2021 u= m 12:48 schrieb Leif Lindholm:
Hi Michael,

Apologies, I've owed you a = response (promised off-list) for a while
now.
<= br class=3D"">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 re= work cycles for
developers.

Look= ing at the changes to (well, the comments in) uncrustify, this
seems to be constrained to:
- Newline after '(' for multi-l= ine function calls.
- Dealing with "(("/"))" for DEBUG macros= .
- Function pointer typedefs:
  - ty= pedef\nEFIAPI
  - closing parentheses indentation
I don't think I've made any secret over the yea= rs that I am not a
massive fan of the EDK2 coding style in ge= neral. So I think for any
of its quirks that are substantial = enough that they require not just
custom configuration but ac= tual new function added to existing code
conformance tools, t= his would be an excellent point to sanitise the
coding style = instead.

Taking these in order:
=
Newline after '('
-----------------
I think we already reached a level of flexibility around this, where<= br class=3D"">we don't actually enforce this (or single argument per
line). Personally, I'd be happy to update the coding style as
required instead.

DEBUG macro parenth= eses
-----------------------
How does uncrustif= y treat DEBUG macros without this modification?
Do we start g= etting everything turned into multi-level indented
multi-line= statements without this change?

Function poin= ter typedefs:
--------------------------
I don'= t see that function pointer typedefs need to rigidly follow the
same pattern as the declaration of functions implementing them. Couldwe update the coding style (if needed) instead?
<= br class=3D"">Best Regards,

Leif

On Mon, Aug 16, 2021 at 16:00:38 -0400, Michael Kubacki wro= te:
The edk2 branch was = created here:
https://github.com/makubacki/edk2/tree/uncr= ustify_poc_2

We have a Project Mu fork wit= h custom changes to the Uncrustify tool to help
comply with E= DK II formatting here:
https://dev.azure.com/projectmu/_git/U= ncrustify

The latest information about the sta= tus and how to experiment with the
configuration file and the= tool are in that fork:
https://dev.azure.com/projectmu/U= ncrustify/_wiki/wikis/Uncrustify.wiki/1/Project-Mu-(EDK-II)-Fork-Readme=

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 configuration file that less strictly but more
reliab= ly formats the code than in the examples in those branches. For
example, remove heuristics that when run against the same set of codemultiple 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 m= ore conservative approach that can be tightened in the future.
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 Uncru= stify against
modified files and if there's any changes, indi= cating a formatting
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 shoul= d be able to post
a "uncrustify_poc_3" branch soon with the r= esults.

Regarding indentation, Marvin is right= that Uncrustify cannot support edk2
indentation style out-of= -box. Some changes are made in that fork to handle
the format= ting. At this point, it can handle the indentation in the cases
I've seen. Uncrustify does potentially give us the ability to massively<= br class=3D"">deploy changes across the codebase in case a decision were ma= de to change
the style.

Thanks,<= br class=3D"">Michael

On 8/16/2021 3:39 PM, Ma= rvin H=C3=A4user wrote:
= Hey Rebecca,

I think even Uncrustify has issue= s with the EDK II indentation style.
You might want to check = the UEFI Talkbox Discord server, I had a brief
chat with Mich= ael about it there. I don't think realistically any tool
supp= orts EDK II's indentation style however, so I'd propose it is
changed. This could be for new submissions only, or actually the entirecodebase could be reformatted at once with a good tool setup. W= hile this
screws with git blame, the (to my understanding) de= cided on CRLF -> LF
change does that anyway, so at least t= wo 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:

I noticed a message on Twitter about a= n idea of using Uncrustify
for EDK2 instead of the ECC tool, = and came across https://www.mail-
<= /blockquote>
archive.com/search?l=3Ddevel@edk2.gro= ups.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 couldcheck out?


Michael= Kubacki: in that message, you said:

"I'm plan= ning to put up a branch that we can use as a reference
for a = conversation around uncrustify in the next couple of
weeks."<= br class=3D"">

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


--
Rebecca Cran




















--Apple-Mail=_69A133B8-10F1-4DBF-97B9-FBC8F5E26E26--