[cfe-dev] address_space pragma

[John McCall via cfe-dev]

> On Aug 1, 2018, at 6:50 PM, Leonard Chan <leonardchan at google.com> wrote:
> 
>> Is your expectation that these address spaces will be exclusively used for diagnostics?
> 
> Yes. This will serve as a way of essentially shortening an attribute
> list in the diagnostic for address_space since this is what's useful
> to us for now, but we are open to expanding this to fit other use
> cases as long as we get this.
> 
>> Should they support promotions between address spaces?
> 
> We weren't planning on this. The idea is that each new address space
> created with this pragma will be a new address space disassociated
> from any previous one.

And these are supposed to work like actual language address spaces, right?
Which is to say, they're not interconvertible at all?  I'm a little confused about how
this fights into a code-analysis framework when it's actually a major semantic
change.

>> Do you have an idea of what the "variable attributes" would look like?
> 
> Should've clarified on this more. This is the syntax of regular
> attributes that you would normally declare in an attribute list but
> space separated. So something like
> 
> ```
> #define __iomem __attribute__((address_space(2), noderef, other_attr(arg)))
> ```
> 
> would be represented as
> 
> ```
> #pragma clang address_space "__iomem" noderef other_attr(arg)
> #define __iomem __attribute__((address_space("__iomem")))
> ```
> 
> Though after experimenting for a bit, I'm running into a few
> unexpected errors and may change the syntax. I've been looking into
> arphaman's patch for the pragma clang attribute and may borrow his
> syntax.

The diagnostic goals could probably be achieved by just making a better effort to
recognize and preserve that an address_space attribute was written with a macro.

John.