On Wed, May 28, 2014 at 2:45 PM, Reid Kleckner <
[email protected]> wrote:
On Wed, May 28, 2014 at 6:42 AM, Aaron Ballman <[email protected]>
wrote:
On Tue, May 27, 2014 at 6:28 PM, Reid Kleckner <[email protected]> wrote:
On Sat, May 24, 2014 at 8:28 AM, Aaron Ballman <[email protected]>
wrote:
My first idea is to add a tablegen property like "HasPrettyPrinter =
0
or 1"
that supresses emission of the default printPretty method. Then
again,
we
kind of want the default version when the GNU and C++11 spellings of
the
attribute are used.
That seems like the wrong way to go about it though, since this is a
new *spelling*, not a wholly new semantic kind of attribute (which I
think we really want to avoid). We could possibly attach a custom
pretty printer to the spelling itself (a la a code block), but that
seems a bit skeezy because the arguments are rather important and the
spelling shouldn't have to care about the arguments.
How about this: when generating the prettyPrint implementation, if there
is
a pragma spelling, call MyAttr::printPrettyPragma(...). Any attribute
with
a pragma spelling will have to provide this method in
lib/AST/AttrImpl.cpp.
So my ultimate goal is for pragma attributes to mirror all of the
other attributes, where we can infer syntax and semantics just from
what's in Attr.td. But it's becoming more obvious to me that the
amount of work required to get there is rather large (mostly due to
the fact that pragma argument syntax is ALL over the place).
As a stopgap solution, it seems reasonable to me to rely on an
AdditionalMember being defined for pragmas (which is basically what
you're suggesting).
So if an attribute has a pragma spelling, it is required to have:
let AdditionalMembers = [{
void printPrettyPragma(raw_ostream &OS, const PrintingPolicy &Policy)
const {
}
}];
Sure, but... I like writing C++ in .cpp files, not .td files. +1 for
defining it out of line in AttrImpl.cpp. :)
That's an understandable desire, but a step in the wrong direction for
two reasons. 1) Anything declarative that we can put into the .td file
belongs in the .td file. There's nothing about this problem which
isn't declarative aside from the fact that we don't have the time
(yet) to make the proper declarations regarding parameter syntax. 2)
Putting it into AttrImpl.cpp decouples the logic from what gets
generated, which is far worse than writing some C++ code in a .td
file. You would have to write an out-of-line definition for
FooAttr::printPrettyPragma where the declaration gets automatically
generated for you elsewhere, which is rather ugly as sin when we
already have an alternative that suffices.
Also, this isn't a whole lot of complex C++ code either. The less of
it you write in the .td file, the more likely it is we will get the
declarative portions down without a mess of refactoring.
~Aaron
pragma_tablegen.patch