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

RFC: Remove inner attributes and inner doc-comments syntax #12341

Closed
liigo opened this issue Feb 17, 2014 · 4 comments
Closed

RFC: Remove inner attributes and inner doc-comments syntax #12341

liigo opened this issue Feb 17, 2014 · 4 comments

Comments

@liigo
Copy link
Contributor

liigo commented Feb 17, 2014

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:

/// The std library's documents, and attributes, go here
#[crate_type="rlib"]
#[crate_id="std"]
pub crate std;

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

@ghost
Copy link

ghost commented Feb 17, 2014

Why do people dislike them so much? I love being able to write

fn foo() { #[inline];
    // ...
}

fn bar() { #[test];
    // ...
}

@liigo
Copy link
Contributor Author

liigo commented Feb 17, 2014

Because of ugly
2014年2月17日 下午7:09于 "György Andrasek" [email protected]写道:

Why do people dislike them so much? I love being able to write

fn foo() { #[inline];
// ...}
fn bar() { #[test];
// ...}


Reply to this email directly or view it on GitHubhttps://github.com//issues/12341#issuecomment-35247574
.

@lilyball
Copy link
Contributor

I strongly disagree with this proposal. Besides requiring pub crate foo; to define crate-level attributes (which I think is pretty bad), this would also prevent modules from defining their own documentation/attributes and instead requiring them to be specified in their parent module's file.

I also prefer the ability to mark up some attributes inside a function instead of outside, if I consider them implementation details.

@emberian
Copy link
Member

Closing. If you would like to pursue this further, please create an RFC using the new RFC process

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
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
flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 7, 2024
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
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

3 participants