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

vim: Tweak how comment nesting works #12308

Merged
merged 1 commit into from
Mar 2, 2014

Conversation

lilyball
Copy link
Contributor

Don't try to match line comments inside of a comment block. That makes
no sense and can highlight differently for people who override their
highlights.

Similarly, don't match a doc-comment inside of a comment block. It
shouldn't be highlighted differently unless it's actually a doc-comment
(and nested comments are obviously not doc comments).

Fixes #12307.

@lilyball
Copy link
Contributor Author

r? @chris-morgan

@flaper87
Copy link
Contributor

LGTM

@chris-morgan
Copy link
Member

In /** x /* y */ z */, this highlights the /* and */ as rustCommentBlock, unlike the rest which is rustCommentBlockDoc. Au contraire, /** inside /* is not rustCommentBlockDoc.

Apart from that, the behaviour (as distinct from highlighting) of the previous implementation remains, including all the caveats: good.

@lilyball
Copy link
Contributor Author

@chris-morgan I intentionally made /** inside of /* not be rustCommentBlockDoc. As for the /* and */ delimiters inside of /** being rustCommentBlock, that's unfortunate. The solution would be to duplicate rustCommentBlockNest into a rustCommentBlockDocNest so it can give the delimiters the same rustCommentBlockDoc syntax. Is it worth it?

Incidentally, I wish I could just remove the matchgroup=rustCommentBlock from rustCommentBlockNest, but I believe that makes it search for contained syntaxes starting from the first character of the delimiter, which is bad, instead of just in the enclosed content.

@chris-morgan
Copy link
Member

Yes, the matchgroup stuff is there for a reason.

Is it worth duplicating the Nest rules for Doc and non-Doc? Well, if you want to get highlighting consistent, I guess it is.

@lilyball
Copy link
Contributor Author

I think I can use ms= and me= instead to adjust the contained area.

@lilyball
Copy link
Contributor Author

Nevermind, it doesn't work right, and there's no way to debug this.

Don't try to match line comments inside of a comment block. That makes
no sense and can highlight differently for people who override their
highlights.

Similarly, don't match a doc-comment inside of a comment block. It
shouldn't be highlighted differently unless it's actually a doc-comment
(and nested comments are obviously not doc comments).

Fixes rust-lang#12307.
@lilyball
Copy link
Contributor Author

I've gone ahead and duplicated the rule so it can highlight correctly.

bors added a commit that referenced this pull request Mar 2, 2014
vim: Tweak how comment nesting works

Reviewed-by: brson
@bors bors merged commit bc35eb7 into rust-lang:master Mar 2, 2014
@lilyball lilyball deleted the vim-nested-comments branch March 25, 2014 02:23
lnicola pushed a commit to lnicola/rust that referenced this pull request Aug 23, 2022
…predicate, r=lowr

Consider bounds on inherent impl in method resolution

There are three type-related things we should consider in method resolution: `Self` type, receiver type, and impl bounds. While we check the first two and impl bounds on trait impls, we've been ignoring the impl bounds on inherent impls. With this patch rust-analyzer now takes them into account and is able to select the appropriate inherent method.

Resolves rust-lang#5441
Resolves rust-lang#12308
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 26, 2024
Look for `implied_bounds_in_impls` in more positions

With this, we lint `impl Trait` implied bounds in more positions:
- Type alias impl trait
- Associated type position impl trait
- Argument position impl trait
  - these are not opaque types, but instead are desugared to `where` clauses, so we need extra logic for finding them (`check_generics`), however the rest of the logic is the same

Before this, we'd only lint RPIT `impl Trait`s.
"Hide whitespaces" and reviewing commits individually might make this easier

changelog: [`implied_bounds_in_impls`]: start linting implied bounds in APIT, ATPIT, TAIT
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

Successfully merging this pull request may close these issues.

Vim plugin highlights single line comments nested within a multi line comment
5 participants