Hi Aaron, Richard suggested moving pragma loop into the clang namespace so that other compilers ignore it. So I added the namespace we talked about in this thread to the Pragma spelling.
I think I understood what you described below. Please let me know if it looks right to you. Tyler
pragma_tablegen.patch
Description: Binary data
On May 30, 2014, at 10:51 AM, Aaron Ballman <[email protected]> wrote: > I'm not certain I was clear in the design I was hoping for. I would > like all consumers to use printPretty. So there should not be an > exposed printPrettyPragma virtual function. Otherwise, the consumer is > forced to write code that checks whether the spelling is a pragma or > not, and pick a function as appropriate. Instead, the tablegenerator > can do this already when generating printPretty. If you look at the > generated AttrImpl.inc, you'll see that all printPretty methods are a > switch method based on the SpellingListIndex. This list index > specifies what spelling variant was used, so there's a new one for > pragma that you're adding. So the generated code should look something > like this: > > case X: { // for whatever X the pragma enum value works out to be > OS << "#pragma "; > printPrettyPragma(OS, Policy); > break; > } > > The printPrettyPragma function is something that the attribute author > must provide as an additional member (preferably as a private method). > > let AdditionalMembers = [{ > private: > void printPrettyPragma(raw_ostream &OS, const PrintingPolicy &Policy) const { > // Magic happens here > } > }]; > > If the author of the attribute fails to provide a printPrettyPragma > function as an additional member when a pragma spelling is present, > the code will fail to compile. > > As for the prefix -- don't worry about it. It's an incremental change > that can be added later. > > ~Aaron > > On Thu, May 29, 2014 at 5:08 PM, Tyler Nowicki <[email protected]> wrote: >> Hi Aaron, >> >> Thanks for all the help with these patches. I’m learning a lot about clang. >> >> Here is an updated patch. I did not add a prefix to the Pragma because I >> don’t really understand it too well, how to use it or test it. I used the >> printPrettyPragma approach described below. >> >> If I missed any changes please let me know. >> >> Tyler >> >> >> >> On May 28, 2014, at 11:59 AM, Aaron Ballman <[email protected]> wrote: >> >> 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 >> >> >>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
