Setting up editors for the GNU/GCC coding style?

Setting up editors for the GNU/GCC coding style?

[David Malcolm]

Is there documentation on setting up text editors to work with our
coding style?  A lot of the next generation of developers aren't using
vi or emacs; they's using VS Code, CLion, and other editors.  Does
anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ ?)
to work well on GCC's own code base.  FWIW I use Emacs; I've dabbed
with VS Code but haven't used it "for real".

I'm hoping to add this to my newbies guide.

Thanks
Dave

Re: Setting up editors for the GNU/GCC coding style?

[Alexander Monakov]

On Thu, 28 Jul 2022, David Malcolm via Gcc wrote:

> Is there documentation on setting up text editors to work with our
> coding style?  A lot of the next generation of developers aren't using
> vi or emacs; they's using VS Code, CLion, and other editors.  Does
> anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ ?)
> to work well on GCC's own code base.  FWIW I use Emacs; I've dabbed
> with VS Code but haven't used it "for real".
> 
> I'm hoping to add this to my newbies guide.

The tricky part is setting it up so it doesn't die indexing the codebase
(e.g. adding the entire toplevel directory probably won't work: it will
try to index the testsuites).

FWIW, CLion documentation shows how to select GNU coding style, but as
above, that's not the main worry:
https://www.jetbrains.com/help/clion/predefined-code-styles.html

Alexander

Re: Setting up editors for the GNU/GCC coding style?

[Tim Lange]

On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc 
<gcc@gcc.gnu.org> wrote:
> Is there documentation on setting up text editors to work with our
> coding style?  A lot of the next generation of developers aren't using
> vi or emacs; they's using VS Code, CLion, and other editors.  Does
> anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ 
> ?)
> to work well on GCC's own code base.  FWIW I use Emacs; I've dabbed
> with VS Code but haven't used it "for real".

I did prepare my first patch(es) with vscode. For debugging, I set up 
vscode to launch gcc with gdbserver as wrapper and then let the vscode 
debugger to connect to the gdbserver. At first, I tried to get the gnu 
coding style to work in the hacky way by using tabSize=8 and rebinding 
tab to 2 spaces but later ditched that because it bothered me more than 
doing just spaces and replacing 8 spaces with 1 tab before sending the 
patch. That still wastes time because all files that I didn't touch 
look ugly unless I temporarily change the tabSize and some comments 
don't use tabs so I can't just replace all 8 spaces with 1 tab. For 
reference, my config files for gcc are available at [0].

- Tim

[0] https://gist.github.com/timll/1c4c542c7c98e3610c14aec19cdf7e91

> 
> I'm hoping to add this to my newbies guide.
> 
> Thanks
> Dave
> 

Re: Setting up editors for the GNU/GCC coding style?

[Jonathan Wakely]

On Thu, 28 Jul 2022 at 20:49, Tim Lange wrote:
>
>
>
> On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc
> <gcc@gcc.gnu.org> wrote:
> > Is there documentation on setting up text editors to work with our
> > coding style?  A lot of the next generation of developers aren't using
> > vi or emacs; they's using VS Code, CLion, and other editors.  Does
> > anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ
> > ?)
> > to work well on GCC's own code base.  FWIW I use Emacs; I've dabbed
> > with VS Code but haven't used it "for real".
>
> I did prepare my first patch(es) with vscode. For debugging, I set up
> vscode to launch gcc with gdbserver as wrapper and then let the vscode
> debugger to connect to the gdbserver. At first, I tried to get the gnu
> coding style to work in the hacky way by using tabSize=8 and rebinding
> tab to 2 spaces but later ditched that because it bothered me more than
> doing just spaces and replacing 8 spaces with 1 tab before sending the
> patch. That still wastes time because all files that I didn't touch
> look ugly unless I temporarily change the tabSize and some comments
> don't use tabs so I can't just replace all 8 spaces with 1 tab.

That's what unexpand(1) is for:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/unexpand.html

Re: Setting up editors for the GNU/GCC coding style?

[Iannetta Paul]

On 2022-07-28 21:00, Alexander Monakov via Gcc wrote:

> On Thu, 28 Jul 2022, David Malcolm via Gcc wrote:
> 
> The tricky part is setting it up so it doesn't die indexing the 
> codebase
> (e.g. adding the entire toplevel directory probably won't work: it will
> try to index the testsuites).
> 
> FWIW, CLion documentation shows how to select GNU coding style, but as
> above, that's not the main worry:
> https://www.jetbrains.com/help/clion/predefined-code-styles.html
> 
> Alexander

Unless I am mistaken, I don't think that modern editors have support for 
autotools based projects, so they won't even attempt indexing the files.

For the indexing, I produce a compile_commands.json file (recording only 
the files compiled by `make all', this includes auto-generated files 
such as config.h, and the insn-something.{h,c} files) with the help of 
https://github.com/gicmo/cdcc, this file is then picked up by the 
language server, which then provides nice autocompletion features.

About configuring recent editors to follow the GNU coding style, I don't 
really know but it should always be possible to register a hook that 
will run `indent` when the file is saved.

Paul

Re: Setting up editors for the GNU/GCC coding style?

[Marc Poulhies]

Iannetta Paul <paul.iannetta@ens-lyon.fr> writes:

Hi Paul :)

> For the indexing, I produce a compile_commands.json file (recording only the
> files compiled by `make all', this includes auto-generated files such as
> config.h, and the insn-something.{h,c} files) with the help of
> https://github.com/gicmo/cdcc, this file is then picked up by the language
> server, which then provides nice autocompletion features.

I'm using the same process, but with the 'bear' command:

  https://github.com/rizsotto/Bear

I know other here are also using it.

As creating the json file can be long, I usually do a non-parallel build
(had issues with parallel jobs) when I'm not coding.

> About configuring recent editors to follow the GNU coding style, I don't really
> know but it should always be possible to register a hook that will run `indent`
> when the file is saved.

There is a clang-format config file in contrib that one can symlink in
the root dir as .clang-format. I hope/guess tools like CLion can pick it
and use it? At least this can be used to indent using clang-format tools
and derivatives (like git-clang-format). In the GCC Rust project, we are
using it (but judging by Jakub's last review for Philip's patch, the
config is maybe not exhaustive, or our setup is not correct).

Marc

Re: Setting up editors for the GNU/GCC coding style?

[Thomas Schwinge]

Hi!

On 2022-07-29T09:36:41+0200, Marc Poulhies via Gcc <gcc@gcc.gnu.org> wrote:
> Iannetta Paul <paul.iannetta@ens-lyon.fr> writes:
>> About configuring recent editors to follow the GNU coding style, I don't really
>> know but it should always be possible to register a hook that will run `indent`
>> when the file is saved.
>
> There is a clang-format config file in contrib that one can symlink in
> the root dir as .clang-format. I hope/guess tools like CLion can pick it
> and use it? At least this can be used to indent using clang-format tools
> and derivatives (like git-clang-format). In the GCC Rust project, we are
> using it (but judging by Jakub's last review for Philip's patch, the
> config is maybe not exhaustive, or our setup is not correct).

Simple answer there: these files are in 'gcc/config/' etc.,
but 'clang-format' is restricted to 'gcc/rust/' only (both in
'.github/workflows/clang-format.yml' and 'CONTRIBUTING.md':
"Running `clang-format` locally").

Unless everyone uses it, using 'clang-format' everywhere is too noisy;
it has a very strict (in my opinion: restrictive) understanding of
"proper" format.  ;-)


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: Setting up editors for the GNU/GCC coding style?

[Richard Earnshaw]

On 28/07/2022 22:43, Iannetta Paul wrote:

> About configuring recent editors to follow the GNU coding style, I don't 
> really know but it should always be possible to register a hook that 
> will run `indent` when the file is saved.

I don't think that's a good idea.  It will result in quite a lot of 
minor changes that will just make diffs confused.  We do have a style, 
but not everything is exactly as GNU indent would lay it out (plus GNU 
indent says quite clearly that it can't handle C++).

R.

Re: Setting up editors for the GNU/GCC coding style?

[Stefan Schulze Frielinghaus]

On Thu, Jul 28, 2022 at 08:53:37PM +0100, Jonathan Wakely via Gcc wrote:
> On Thu, 28 Jul 2022 at 20:49, Tim Lange wrote:
> >
> >
> >
> > On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc
> > <gcc@gcc.gnu.org> wrote:
> > > Is there documentation on setting up text editors to work with our
> > > coding style?  A lot of the next generation of developers aren't using
> > > vi or emacs; they's using VS Code, CLion, and other editors.  Does
> > > anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ
> > > ?)
> > > to work well on GCC's own code base.  FWIW I use Emacs; I've dabbed
> > > with VS Code but haven't used it "for real".
> >
> > I did prepare my first patch(es) with vscode. For debugging, I set up
> > vscode to launch gcc with gdbserver as wrapper and then let the vscode
> > debugger to connect to the gdbserver. At first, I tried to get the gnu
> > coding style to work in the hacky way by using tabSize=8 and rebinding
> > tab to 2 spaces but later ditched that because it bothered me more than
> > doing just spaces and replacing 8 spaces with 1 tab before sending the
> > patch. That still wastes time because all files that I didn't touch
> > look ugly unless I temporarily change the tabSize and some comments
> > don't use tabs so I can't just replace all 8 spaces with 1 tab.
> 
> That's what unexpand(1) is for:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/unexpand.html

I gave unexpand from GNU coreutils 8.32 a try.  Looks like it cannot
deal with form feeds or maybe I'm missing something?

$ bash -c "printf 'foo\n\f\n        bar\n'" | unexpand -
foo
unexpand: input line is too long

Re: Setting up editors for the GNU/GCC coding style?

[Martin Liška]

On 7/28/22 21:49, Tim Lange wrote:
> 
> 
> On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc <gcc@gcc.gnu.org> wrote:
>> Is there documentation on setting up text editors to work with our
>> coding style?  A lot of the next generation of developers aren't using
>> vi or emacs; they's using VS Code, CLion, and other editors.  Does
>> anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ ?)
>> to work well on GCC's own code base.  FWIW I use Emacs; I've dabbed
>> with VS Code but haven't used it "for real".
> 
> I did prepare my first patch(es) with vscode. For debugging, I set up vscode to launch gcc with gdbserver as wrapper and then let the vscode debugger to connect to the gdbserver. At first, I tried to get the gnu coding style to work in the hacky way by using tabSize=8 and rebinding tab to 2 spaces but later ditched that because it bothered me more than doing just spaces and replacing 8 spaces with 1 tab before sending the patch. That still wastes time because all files that I didn't touch look ugly unless I temporarily change the tabSize and some comments don't use tabs so I can't just replace all 8 spaces with 1 tab. For reference, my config files for gcc are available at [0].

There's a vscode issue that is about the unsupported expansion of 8 spaces to a tab:
https://github.com/microsoft/vscode/issues/42740

Btw. can we for the future leave this weird mix usage? Is it really an useful selection?

Cheers,
Martin

> 
> - Tim
> 
> [0] https://gist.github.com/timll/1c4c542c7c98e3610c14aec19cdf7e91
> 
>>
>> I'm hoping to add this to my newbies guide.
>>
>> Thanks
>> Dave
>>
> 
> 

Re: Setting up editors for the GNU/GCC coding style?

[Jonathan Wakely]

On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> I gave unexpand from GNU coreutils 8.32 a try.  Looks like it cannot
> deal with form feeds or maybe I'm missing something?
>
> $ bash -c "printf 'foo\n\f\n        bar\n'" | unexpand -
> foo
> unexpand: input line is too long

Which linux distro are you using? I see this error on Fedora and
Centos 8 but not on recent Debian or Ubuntu systems.

I've reported a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2112870

Re: Setting up editors for the GNU/GCC coding style?

[Stefan Schulze Frielinghaus]

On Mon, Aug 01, 2022 at 12:25:21PM +0100, Jonathan Wakely wrote:
> On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> > I gave unexpand from GNU coreutils 8.32 a try.  Looks like it cannot
> > deal with form feeds or maybe I'm missing something?
> >
> > $ bash -c "printf 'foo\n\f\n        bar\n'" | unexpand -
> > foo
> > unexpand: input line is too long
> 
> Which linux distro are you using? I see this error on Fedora and
> Centos 8 but not on recent Debian or Ubuntu systems.

I can reproduce this on Fedora {33,34,35} and on Ubuntu 20.04 it seems
to work.

Re: Setting up editors for the GNU/GCC coding style?

[Jonathan Wakely]

On Mon, 1 Aug 2022 at 13:16, Stefan Schulze Frielinghaus wrote:
>
> On Mon, Aug 01, 2022 at 12:25:21PM +0100, Jonathan Wakely wrote:
> > On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> > > I gave unexpand from GNU coreutils 8.32 a try.  Looks like it cannot
> > > deal with form feeds or maybe I'm missing something?
> > >
> > > $ bash -c "printf 'foo\n\f\n        bar\n'" | unexpand -
> > > foo
> > > unexpand: input line is too long
> >
> > Which linux distro are you using? I see this error on Fedora and
> > Centos 8 but not on recent Debian or Ubuntu systems.
>
> I can reproduce this on Fedora {33,34,35} and on Ubuntu 20.04 it seems
> to work.

There's a fix in Fedora rawhide now, which will also make it into
RHEL, CentOS, and (I assume) F35 and F36.