public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Liming Gao" <liming.gao@intel.com>
To: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Feng, Bob C" <bob.c.feng@intel.com>
Subject: Re: [PATCH] BaseTools/Conf/gitattributes: fix "--function-context" for *.h and *.c
Date: Fri, 17 Jan 2020 00:56:36 +0000	[thread overview]
Message-ID: <1529165fc50e49e3abdf073f079c1efd@intel.com> (raw)
In-Reply-To: <20200117005102.GJ20629@bivouac.eciton.net>

Leif:
  .act is same to .aslc. There are no cases in open source. 

Thanks
Liming
-----Original Message-----
From: Leif Lindholm <leif.lindholm@linaro.org> 
Sent: 2020年1月17日 8:51
To: Gao, Liming <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>; devel@edk2.groups.io; Feng, Bob C <bob.c.feng@intel.com>
Subject: Re: [PATCH] BaseTools/Conf/gitattributes: fix "--function-context" for *.h and *.c

Liming,

Hence the "possibly" :)

Although, I agree, grouping it with .aslc (which definitely *is* C), was a bit confusing.

I couldn't actually find any .act in the tree - are those obsolete, or do we simply not have any in the tree? (If the latter, should we add something in order to support simple build tests?)

Regards,

Leif

On Fri, Jan 17, 2020 at 00:22:00 +0000, Gao, Liming wrote:
> Leif:
>   Vfr is not C style source file. It can't be regarded as C source file. 
> 
> Laszlo:
>    Is there such support for the assembly file, such as .nasm?
> 
> Thanks
> Liming
> -----Original Message-----
> From: Leif Lindholm <leif.lindholm@linaro.org>
> Sent: 2020年1月17日 5:55
> To: Laszlo Ersek <lersek@redhat.com>
> Cc: devel@edk2.groups.io; Feng, Bob C <bob.c.feng@intel.com>; Gao, 
> Liming <liming.gao@intel.com>
> Subject: Re: [PATCH] BaseTools/Conf/gitattributes: fix 
> "--function-context" for *.h and *.c
> 
> On Thu, Jan 16, 2020 at 19:49:29 +0100, Laszlo Ersek wrote:
> > The "--function-context" ("-W") option of git-diff displays the 
> > entire body of a modified function, not just small modified hunks 
> > within the function. It is useful for reviewers when the code 
> > changes to the function are small, but they could affect, or depend 
> > on, control flow that is far away in the same function.
> > 
> > Of course, the size of the displayed context can be controlled with 
> > the "-U" option anyway, but such fixed-size contexts are usually 
> > either too small, or too large, in the above scenario.
> > 
> > It turns out that "--function-context" does not work correctly for 
> > *.h and *.c files in edk2. In particular, labels for the goto 
> > instruction (which the edk2 coding style places in the leftmost 
> > column) appear to terminate "--function-context".
> > 
> > The "git" utility contains built-in hunk header patterns for the C 
> > and
> > C++ languages. However, they do not take effect in edk2 because we
> > don't explicitly assign the "cpp" git-diff driver to our *.h and *.c 
> > files. The
> > gitattributes(5) manual explains that this is required:
> > 
> > >            There are a few built-in patterns to make this easier, and
> > >            tex is one of them, so you do not have to write the above in
> > >            your configuration file (you still need to enable this with
> > >            the attribute mechanism, via .gitattributes). The following
> > >            built in patterns are available:
> > >
> > >            [...]
> > >
> > >            *   cpp suitable for source code in the C and C++
> > >                languages.
> > 
> > The key statement is the one in parentheses.
> > 
> > Thus, mark our *.h and *.c files as belonging to the "cpp" git-diff 
> > driver.
> > 
> > This change has a dramatic effect on the following command, for example:
> > 
> > $ git show -W 2ef0c27cb84c
> 
> This looks really good, I didn't realise we weren't actually using properly C-aware diff by default. And thank you for the perfect level of background.
> 
> However, if doing this change, would we want to apply it to all source code types supported by BaseTools (i.e. referenced in build_rule.template)?
> 
> That would mean:
> 
> .c
> .cc
> .C
> .CC
> .cpp
> .Cpp
> .CPP
> .h
> .H
> 
> and possibly
> 
> .act
> .aslc
> .vfr
> .Vfr
> .VFR
> 
> /
>     Leif
> 
> > 
> > Cc: Bob Feng <bob.c.feng@intel.com>
> > Cc: Leif Lindholm <leif.lindholm@linaro.org>
> > Cc: Liming Gao <liming.gao@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >  BaseTools/Conf/gitattributes | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/BaseTools/Conf/gitattributes 
> > b/BaseTools/Conf/gitattributes index 58b93e9d4c27..8b8b4b92105b 
> > 100644
> > --- a/BaseTools/Conf/gitattributes
> > +++ b/BaseTools/Conf/gitattributes
> > @@ -17,3 +17,5 @@
> >  *.fdf     diff=ini
> >  *.fdf.inc diff=ini
> >  *.inf     diff=ini
> > +*.h       diff=cpp
> > +*.c       diff=cpp
> > --
> > 2.19.1.3.g30247aa5d201
> > 

  reply	other threads:[~2020-01-17  0:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 18:49 [PATCH] BaseTools/Conf/gitattributes: fix "--function-context" for *.h and *.c Laszlo Ersek
2020-01-16 21:54 ` Leif Lindholm
2020-01-17  0:22   ` Liming Gao
2020-01-17  0:51     ` Leif Lindholm
2020-01-17  0:56       ` Liming Gao [this message]
2020-01-17  8:30         ` Laszlo Ersek
2020-01-17 13:05           ` Leif Lindholm
2020-01-17 18:09             ` Laszlo Ersek
2020-01-17 19:37               ` Leif Lindholm
2020-01-19  1:47                 ` Liming Gao
2020-01-17  8:24     ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1529165fc50e49e3abdf073f079c1efd@intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox