Whitelist attributes for 1.0

[huonw]

There's probably a few/many attributes the compiler supports that we do not wish to stabilise at 1.0, but it may be hard to catch them all. We could have a whitelist of attributes that every attribute access is checked against, emitting an error if it is not in the whitelist and the feature gate (e.g. non_whitelisted_attributes) is not enabled.

[brson]

The one I saw today and was worried about was recursion_limit.

[nikomatsakis]

The recursion_limit is there to prevent us from looping infinitely (or overflowing the stack) in various cases that can grow without bound. Examples are trait resolution and monomorphization. Right now we have a single limit that you can raise for all things. It's conceivable we might want to change the design -- for example, a scale factor might be better than an absolute value. Still, I'd prefer to have something finalized and in place for 1.0, because some programs will need this tuning knob (servo has used it, for example). @brson's concern was that the correct value for this knob is implementation dependent: this is somewhat true. The algorithms are inherently unbounded, but the depth required can be affected by various impl details such as the choice of iteration order or the use of caching.

[nikomatsakis]

Seems related to rust-lang/rfcs#572

[brson]

nbd if it doesn't happen

[brson]

The mechanism is already in place for this. feature_gate.rs classifies all known attributes, some as gated. The only thing left to do here I think is decide that the current classification is correct.

[sfackler]

I believe this has been done and can be closed.

[Gankra]

Certainly too late to change, regardless.