syntax: add a local_data_key macro that creates a key for access to the TLS.

[huonw]

This allows the internal implementation details of the TLS keys to be
changed without requiring the update of all the users. (Or, applying
changes that have to be applied for the keys to work correctly, e.g.
forcing LLVM to not merge these constants.)

[huonw]

r? @alexcrichton

(This was prompted by this comment, since this would mean that the user of tls keys don't have to remember to put #[address_significant] on the declaration.)

[alexcrichton]

Could we get the syntax local_data_key!(name: type) ? I think conditions manage to do this

[alexcrichton]

The only thing which is unfortunate about this is that you can still create your own local data keys manually. Without a good way to avoid this, I'm worried about having some users use one way and others use another and then you get bugs because the two are incompatible.

I can't really think of a good way to prevent users from creating keys while only this compiler macro can, do you have any ideas in that respsect?

[alexcrichton]

I was thinking about this some more and I thought that it was very similar to conditions in that there's two ways to define them (it's just one's more convenient than the other). It seems like this kinda falls in the same category, so I'm ok with it on that grounds.

On the other hand, I'd still be wary of marking all statics as address_insignificant by default. In the case of ifmt, everything that was collapsed was compiler generated, so it's guaranteed to be collapsible. In the case of generic statics, you have to be very careful. That's kinda a separate discussion though.

Basically, with a tweak to the declaration syntax and with some updated dox, r+

[huonw]

Fixed the syntax, and updated the std::local_data docs to use it, but it can't be used in the codebase itself until a snapshot.

Agree that that this is similar to the situation with conditions (the address_insignificant suggestion is an entirely separate discussion, I was just using that possibility as an additional excuse to make the syntax nicer).