-
Notifications
You must be signed in to change notification settings - Fork 13.3k
RFC: Remove inner attributes and inner doc-comments syntax #12341
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
Comments
Why do people dislike them so much? I love being able to write fn foo() { #[inline];
// ...
}
fn bar() { #[test];
// ...
} |
Because of ugly
|
I strongly disagree with this proposal. Besides requiring I also prefer the ability to mark up some attributes inside a function instead of outside, if I consider them implementation details. |
Closing. If you would like to pursue this further, please create an RFC using the new RFC process |
make `files.excludeDirs` work There's a small issue because if all projects are excluded, this: https://github.com/rust-lang/rust-analyzer/blob/01d412f4d7bd7ef21a7e8f0461e9ba3439e3c4bf/crates/rust-analyzer/src/main_loop.rs#L114 will be shown. I thought about not showing it if `files.excludeDirs` is set, but that is not necessarily correct. Fixes rust-lang#7755
Check for try blocks in `question_mark` more consistently Fixes rust-lang#12337 I split this PR up into two commits since this moves a method out of an `impl`, which makes for a pretty bad diff (the `&self` parameter is now unused, and there isn't a reason for that function to be part of the `impl` now). The first commit is the actual relevant change and the 2nd commit just moves stuff (github's "hide whitespace" makes the diff easier to look at) ------------ Now for the actual issue: `?` within `try {}` blocks desugars to a `break` to the block, rather than a `return`, so that changes behavior in those cases. The lint has multiple patterns to look for and in *some* of them it already does correctly check whether we're in a try block, but this isn't done for all of its patterns. We could add another `self.inside_try_block()` check to the function that looks for `let-else-return`, but I chose to actually just move those checks out and instead have them in `LintPass::check_{stmt,expr}`. This has the advantage that we can't (easily) accidentally forget to add that check in new patterns that might be added in the future. (There's also a bit of a subtle interaction between two lints, where `question_mark`'s LintPass calls into `manual_let_else`, so I added a check to make sure we don't avoid linting for something that doesn't have anything to do with `?`) changelog: [`question_mark`]: avoid linting on try blocks in more cases
The problem
There is a big pain to distinguish inner- and outer- attributes, the same as doc-comments, for a long time. Two different syntax, make it no clarity and no consistency. Especially, the semicolon in inner-attr is most ambiguous (for newbies). They are many comments in #2569 about this.
The solution
We remove the inner-attributes and inner-doc-comments, and we always use outer ones everywhere. In the past, there was no place to write crate-scope outer-attributes and outer-doc-comments. But now,
crate
is already a keyword, we can reuse it to define crates (#12107), and place attributes and doc-comments on top of it:src/libstd/lib.rs:
As a result, inner attributes and doc-comments are not required any more, we can remove them entirely. Perhaps we should keep the
//!
comment syntax, if most people like it (I do).The text was updated successfully, but these errors were encountered: