Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out a way to keep track of attributes #7318

Closed
brson opened this issue Jun 23, 2013 · 7 comments
Closed

Figure out a way to keep track of attributes #7318

brson opened this issue Jun 23, 2013 · 7 comments

Comments

@brson
Copy link
Contributor

brson commented Jun 23, 2013

There are a lot of attributes in use. They are nearly undocumentedand impossible to catalog automatically.

The wiki is out of date: https://github.com/mozilla/rust/wiki/Doc-attributes

@alexcrichton
Copy link
Member

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).

@bstrie
Copy link
Contributor

bstrie commented Jul 12, 2013

@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.

@alexcrichton
Copy link
Member

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?

@catamorphism
Copy link
Contributor

Just a bug, de-nominating

@alexcrichton
Copy link
Member

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!

@huonw
Copy link
Member

huonw commented Aug 4, 2014

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)

@steveklabnik
Copy link
Member

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

flip1995 pushed a commit to flip1995/rust that referenced this issue May 5, 2022
Fix missing whitespace in `collapsible_else_if` suggestion

changelog: Fix missing whitespace in [`collapsible_else_if`] suggestion
closes rust-lang#7318
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants