Figure out a way to keep track of attributes #7318

Activity

1. alexcrichton commented on Jun 23, 2013

   

   alexcrichton

   on Jun 23, 2013

   Member

   More actions

   One way to implement this would make it a compile-time failure to have an attribute which is of an unknown name. This would at least force all the names to be in one location (and not be that bad of an idea).
2. bstrie commented on Jul 12, 2013

   

   bstrie

   on Jul 12, 2013

   Contributor

   More actions

   @alexcrichton I think it's a valid use-case for attributes to encode metadata that doesn't necessarily have an impact on compilation, such as project-specific attributes or attributes usable only by a certain tool. Forcing compilation to fail when encountering something that's not related to compilation seems like a major pain.

   Nominating for Well-Covered.
3. alexcrichton commented on Jul 12, 2013

   

   alexcrichton

   on Jul 12, 2013

   Member

   More actions

   Oh I think we're talking about different things. I thought the bug was "document somewhere what all the compiler-recognized attributes are", and it sounds like your use case is "emitting user-defined attributes to compiled crates".

   I think both are correct, and my initial idea of denying unknown attributes shouldn't be done. @bstrie I think that your use case isn't covered by this bug. This looks like it's only figuring out how to document the smattering of attributes the compiler accepts. Perhaps open another bug about emitting and possibly somehow processing user-defined attributes on items?
4. catamorphism commented on Sep 5, 2013

   

   catamorphism

   on Sep 5, 2013

   Contributor

   More actions

   Just a bug, de-nominating
5. alexcrichton commented on Dec 7, 2013

   

   alexcrichton

   on Dec 7, 2013

   Member

   More actions

   Some excellent support for this was added in #10316, but this still doesn't have a central user-visible list which is documentable. @klutzy made some awesome progress on this though!
6. huonw commented on Aug 4, 2014

   

   huonw

   on Aug 4, 2014

   Contributor

   More actions

   All attribute lookups go either through a single function or are in a whitelist (at least, it's a bug if they use neither, and the whitelist is a bug itself, #14406, #14407, #14408) so that #14373 unused attribute lint works (the new version of #10316), so we can get a comprehensive list of "top-level" attributes either instrumenting that function, or with some grepping (+ the whitelist above):

   $ { git grep '\.check_name('; git grep 'has_attr('; } | sed -n 's/.*"\([^"]*\)".*/\1/p'
   crate_name
   crate_id
   crate_type
   crate_id
   feature
   main
   ignore
   must_use
   doc
   lang
   phase
   cfg
   unsafe_no_drop_flag
   packed
   simd
   rustc_variance
   

   (NB. rustc::middle::ty::has_attr is a proxy around check_name)
7. steveklabnik commented on Jan 21, 2015

   

   steveklabnik

   on Jan 21, 2015

   Contributor

   More actions

   I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

   This issue has been moved to the RFCs repo: rust-lang/rfcs#626
8. steveklabnik

   closed this as completedon Jan 21, 2015
9. flip1995

   added a commit that references this issue on May 5, 2022

   Auto merge of rust-lang#8729 - Serial-ATA:issue-7318, r=Manishearth

   ...

   This issue will close once commit cf68cad is merged into the 'main' branch.

   cf68cad
10. U007D

    added a commit that references this issue on Aug 21, 2026

    Merge rust-lang#7318

    ...

    e1190ba