[PATCH] D141714: Fix ast print of variables with attributes

Giuliano Belinassi via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 7 11:27:36 PST 2023


giulianobelinassi added a comment.

Hi, Aron.

Just to make myself clear: What I need to do is that the clang dumps for C files are also accepted by GCC as input.

Here is why I wanted to output the attribute on middle:

https://godbolt.org/z/6aPc6aWcz

As you can see, GCC complains of `__attributes__` output on the right side of functions with bodies.

But overall, perhaps what should be output in the dumps are the following (please check if you agree with me):

1- Attributes in variables should be output to the right side, as it was done before. That is:

  int var __attribute__((unused)) = 0;

2- Variables or functions declared with __declspec attributes should go to the left side, as does MSVC says is recommended. That is:

  __declspec(thread) int var = 0;
  __declspec(noinline) int f(void);
  __declspec(noinline) int f(void) { return 0; }

3- Functions __prototypes__ should have its attributes output to the right side, that means:

  int f(void) __attribute__((unused));

4- But attributes specified in function declaration __with body__ should go to the __left__ side __because GCC rejects outputing them on the right side__, as:

  __attribute__((unused)) int f(void) { return 0; }

-----

The result of this choice would be that the following K&R function __as input__ (notice how it is not clear where the __attribute__ is being applied to:

  int f(i)
   __attribute__((unused)) int i;
  { return 0; }

would be dumped as:

  __attribute__((unused)) int f(i)
  int i;
  { return 0; }

But in practical terms, GCC would accept it without problems and it is clear where the __attribute__ is being applied to. Outputting to the right side has some ambiguity here, which is what I want to avoid.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141714/new/

https://reviews.llvm.org/D141714



More information about the cfe-commits mailing list