[cfe-dev] address_space pragma

[Leonard Chan via cfe-dev]

As I have it now, I store a map of source locations to macro
definition names as they are being parsed and that's where I attempt
to find the attribute. Since the printing of the address_space is
controlled by the qualifier, I added an extra field to the qualifier
instead for storing the macro name. I can get this name during the
address space attribute construction where the source location of
address_space is available to me.

Would you mind if I added you as a reviewer to this patch after I clean it up?
On Thu, Aug 2, 2018 at 3:38 PM John McCall <rjmccall at apple.com> wrote:
>
> > 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.