[cfe-dev] address_space pragma

[John McCall via cfe-dev]

> On Aug 2, 2018, at 5:41 PM, Leonard Chan <leonardchan at google.com> wrote:
> 
> On Thu, Aug 2, 2018 at 2:33 PM John McCall <rjmccall at apple.com> wrote:
>> 
>>> On Aug 2, 2018, at 5:28 PM, Leonard Chan <leonardchan at google.com> wrote:
>>> 
>>> Ok. So we will no longer use the pragma. We will instead opt for your
>>> suggestion of printing the macro. So the new goals are now:
>>> 
>>> - Having address_space() accept strings in addition to integers to
>>> represent unique address spaces
>> 
>> Is this still important if you get the diagnostic improvement?  If you were declaring address
>> spaces somehow, this seems fine, but I don't really want to make address_space("whatever")
>> implicitly declare an address space with specific semantics when it's not hard to imagine
>> wanting that for other purposes in the future.
> 
> Not entirely. This was something that's still remnant of when we were
> using pragma. It's something that would be nice for us now, but could
> also be discussed later down the line.
> 
>>> - Changing the type printer to print the macro instead of the whole
>>> attribute if the attribute was passed a string instead of an int.
>> 
>> I don't know that the latter needs to be restricted; it seems like a nice usability improvement
>> for all address-space users.
> 
> Ok, so in general if address_space is used in a macro, then print the macro.

Yeah.  You'll need to record this spelling information in the AttributedType, since
the Type won't otherwise have a source location attached.

I'm not sure we actually make an AttributedType for address_space, but doing
so is reasonable.

We should do a quick parse of the macro's token sequence to verify that it's just
an attribute.  Unfortunately, I'm not really sure how to do that.

John.