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

Implement expect attribute from RFC 2383, "Lint Reasons RFC" #85549

Closed
9 tasks done
nikomatsakis opened this issue May 21, 2021 · 10 comments
Closed
9 tasks done

Implement expect attribute from RFC 2383, "Lint Reasons RFC" #85549

nikomatsakis opened this issue May 21, 2021 · 10 comments
Assignees
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. F-lint_reasons `#![feature(lint_reasons)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

nikomatsakis commented May 21, 2021

This issue is part of #54503. It is specifically focused on implementing the #[expect] attribute for lints.


A working lint implementation can be found in #87835. The implementation still left the to-dos open for follow-up PRs:

The open questions will be asked in the RFC Tracking issue 🙃

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels May 21, 2021
@nikomatsakis
Copy link
Contributor Author

Here are some high-level mentoring instructions. Each of these could be a commit or even a PR (I like doing things in stages):

Probably a good next step is to start looking into the lint code or reading the rustc-dev-guide section on lints. This is going to have to be a bit different than the existing lint infrastructure, though. The way that lints normally work is:

  • when you would generate a lint, you lookup the lint level using the lint_levels query.
  • once you know the level, you can emit the lint

The challenge here is that this not an ordinary lint level. Hmm, this is going to take some thought! We have to find the best way to integrate this into the incremental system, and it's actually kind of non-trivial. I'll ponder it a bit.

@nikomatsakis
Copy link
Contributor Author

cc @xFrednet -- feel free to "rustbot claim" this issue

@xFrednet
Copy link
Member

Very, very awesome. Thank you very much for taking up the role of mentoring me! @nikomatsakis

I've started to work on this implementation partially already by adding the expect attribute as a lint level. Similar to how @JohnTitor has done it in this commit. I was debating if this should actually be a lint level at all. I believe that it makes sense and this also allows the reuse of the LintLevelsBuilder. In either case it will be good enough for a prototype and later adjustment.

The feature flag has already been implemented as lint_reasons. The name might not be descriptive but splitting them into two features where the expect-feature requires the reasoning feature would be weird.

The next step is not to actually track the expectations. My plan looks roughly like this:

  1. Collect all expectations (This can be done by the LintLevelsBuilder or a more specific walker if needed)
  2. Save these expectations in an accessible manner
  3. Now we start the normal lint passes
    1. This includes all lint passes
    2. If a lint is emitted it will check which level is set for it in the specific context
    3. If the level is expect it will be suppressed and notify the expectation-collection that
      a lint has been issued at this location
  4. After all lint passes are done it will be checked if the collected expectations have been met. A message will be issued if not.

What do you think about this plan?

My main road block is that I'm not sure where to store the expectation-collection (Step 2). I first tried to save them in the LintLevelsBuilder but the struct gets recreated for every lint emission and is therefor not really a possibility. My current sights are either on storing them in the Session or the LintStore but both feel not 100% correct 🤔

Some background about my previous work: I'm a contributor to Clippy and fairly fluent when it comes to the diagnostic interfaces. The internals are a bit new though.

@rustbot claim

@nikomatsakis
Copy link
Contributor Author

I opened a topic on Zulip to discuss how to manage the integration into the incremental system:

https://zulip-archive.rust-lang.org/241847tcompilerwgincrcomp/33135implementingtheexpectRFC.html

@xFrednet
Copy link
Member

Okay, I'm sadly not very knowledgeable when it comes to rust's incremental compilation. So, I'll most likely only be a side reader in the stream for now. For reference, is there a state or session saved between the compilation runs?

@nikomatsakis
Copy link
Contributor Author

@xFrednet I recommend reading about the query system and the incremental system

@xFrednet
Copy link
Member

I'm starting to see the problem with my idea. Then let's wait for a bit to see if someone suggests something on Zulip or if either one of us gets an idea. 🤔

@xFrednet
Copy link
Member

Hey reader, this is a quick breakdown of what I found while digging though the compiler to find a starting point for this implementation. It's probably only interesting if you plan to implement this or some other central diagnostic tracking thingy.

Details diagnostic emission breakdown

Collapsed detailed breakdown

This is just a quick breakdown and not really proofread as I don't expect it to read in details. So please excuse any typos 😅. This will also focus on lints but it should be pretty much the same for other diagnostics.

Incremental compilation diagnostics

So, first of all it was mentioned on Zulip that "Diagnostics are already saved and replayed by the incr. comp. engine.". The code for the replay can be found here 1. The loading does a bunch of magic, but the important part is that it emits the loaded diagnostics via rustc_errors::Handler::emit_diagnostic with an instance that is stored in the current session. This means we can collect emitted lints from that point forward.

Normal lint emission

The second question was how lints end up being added to the cache of the incremental compilation. I won't show the complete call stack because it is all over the place and not very helpful, but there are a few important points here:

  1. Entry point: The actual lint emission start by calling struct_span_lint on the current LintContext it also passes a closure with it called decorate, that is used to create the lint message at the end.
  2. The lint information and closure get passed around until it ends up in rustc_middle::lint::struct_lint_level(lint, lint_level, span, decorate, ..). Now here is something important we return if the lint_level is Allow.
    1. This is important as it means that we don't track and therefor not save allowed lints between sessions. The interesting question would be if query system is sensitive to this and relints the module if the passed console arguments about lint level change. This is more a side note for later testing :)
    2. Anyways... There are some further checks and additions which are all not that important, and then we call the decorate closure with a DiagnosticBuilder.
  3. Inside the decorate closure: The passed DiagnosticBuilder is used to add additional information etc. The builder requires the call of DiagnosticBuilder::cancelled() which would simply cancel the emission or DiagnosticBuilder::emit() (The builder will panic during the drop otherwise, so nice protection there!)
  4. Following the branch of DiagnosticBuilder::emit() leads us to rustc_error::HandlerInner::emit_diagnostic(diag) and this is where the magic happen and where we rejoin the diagnostics that have been loaded by the incremental compilation implementation.

rustc_error::HandlerInner::emit_diagnostic(diag)

The function can be found here 2.

What it does:

  1. It calls (*TRACK_DIAGNOSTICS)(diagnostic); with diagnostic being the created diagnostic from the builder.
    1. TRACK_DIAGNOSTICS is a callback to here 3
    2. This callback adds the diagnostic to the collection of diagnostics inside the current ImplicitCtxt object. This object collects the diagnostics from this thread and later passes them on to TyCtxt::store_diagnostic(diagnostic).
    3. The calls are then simply forwarded to TyCtxt::on_disk_cache.store_diagnostics(diagnostic) 4. This function collects all diagnostics during the run and later saves them to
  2. It inserts the emitted code into rustc_error::HandlerInner::emitted_diagnostic_codes.insert(code.clone());.
  3. It checks if this specific diagnostic has been emitted before by comparing the hash with rustc_error::HandlerInner::emitted_diagnostics
  4. Then inserts its hash into rustc_error::HandlerInner::emitted_diagnostics
  5. The last thing it does it call rustc_error::HandlerInner::emitter.emit_diagnostic(diagnostic); which basically just outputs the diagnostic to the console/json or some other medium. This part can be ignored here.

Summary

  1. Only lints with a level above Allow are even emitted.
  2. Every emission (also the ones loaded from cache) are passed to rustc_error::HandlerInner::emit_diagnostic()
    1. This function passed the diagnostic to the ImplicitCtxt and therefore indirectly to TyCtxt which passes them on to the on_disk_cache instance. Every emitted diagnostics during a session can be found there, but a warning above the field states "Do not access this directly" and it can be None if incremental compilation is turned off. So, this is not really an option for the implementation unless we want to track the diagnostics inside TyCtxt as well.
    2. The rustc_error::HandlerInner is one central instance that is used for all emissions and already tracks some information like emitted diagnostic hashes and error codes. It would therefore most likely also be the right place to store all lint emissions with their source span and level.

Further steps

I'll now investigate some things and then try to add basic lint tracking inside rustc_error::HandlerInner. If that works it should be possible to add a new query that checks if all expectations have been met. (This is obviously a bit simplified because we still need to check some stuff when it comes to incremental compilation... But that's a problem for tomorrow's @xFrednet)

bors added a commit to rust-lang-ci/rust that referenced this issue Mar 3, 2022
…th-ids, r=wesleywiser

Implementation of the `expect` attribute (RFC 2383)

This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute.

### Example
#### input
```rs
// required feature flag
#![feature(lint_reasons)]

#[expect(unused_mut)] // Will warn about an unfulfilled expectation
#[expect(unused_variables)] // Will be fulfilled by x
fn main() {
    let x = 0;
}
```

#### output

```txt
warning: this lint expectation is unfulfilled
  --> $DIR/trigger_lint.rs:3:1
   |
LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation
   |          ^^^^^^^^^^
   |
   = note: `#[warn(unfulfilled_lint_expectations)]` on by default
```

### Implementation

This implementation introduces `Expect` as a new lint level for diagnostics, which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query.

The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission, while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise, a new lint message will be emitted.

The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage, it's not possible to create a stable identifier. The level instead stores an unstable identifier, which is later converted to a stable `LintExpectationId`.

### Followup TO-DOs
All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them:

* [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute.
   * This should be easily possible, but I wanted to get some feedback before putting more work into this.
   * This could also be done in a new PR to not add to much more code to this one
* [ ] Update unstable documentation to reflect this change.
* [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics)

### Open questions
I also have a few open questions where I would like to get feedback on:
1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](rust-lang/rfcs#2383 (comment)), suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](rust-lang/rfcs#2383 (comment))). No real conclusion was drawn on that point from my understanding. Is this still open for discussion, or was this discarded with the merge of the RFC?
2. How should the expect attribute deal with the new `force-warn` lint level?

---

This approach was inspired by a discussion with `@LeSeulArtichaut.`

RFC tracking issue: rust-lang#54503

Mentoring/Implementation issue: rust-lang#85549

[`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html
[`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html
[`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels
[`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html
[`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html
@xFrednet xFrednet added the F-lint_reasons `#![feature(lint_reasons)]` label Mar 6, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 14, 2022
…-party, r=flip1995,wesleywiser

Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383)

This PR updates unstable `ExpectationIds` in stashed diagnostics and adds some asserts to ensure that the stored expectations are really empty in the end. Additionally, it handles the `#[expect(unfulfilled_lint_expectations)]` case.

According to the [Errors and lints docs](https://rustc-dev-guide.rust-lang.org/diagnostics.html#diagnostic-levels) the `error` level should only be used _"when the compiler detects a problem that makes it unable to compile the program"_. As this isn't the case with `#[expect(unfulfilled_lint_expectations)]` I decided to only create a warning. To avoid adding a new lint only for this case, I simply emit a `unfulfilled_lint_expectations` diagnostic with an additional note.

---

r? `@wesleywiser` I'm requesting a review from you since you reviewed the previous PR rust-lang#87835. You are welcome to reassign it if you're busy 🙃

rfc: [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html)

tracking issue: rust-lang#85549

cc: `@flip1995` In case you're also interested in this :)
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 6, 2022
…esleywiser

Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang#94953

cc: rust-lang#85549

r? `@wesleywiser`

cc: `@rust-lang/rustdoc`
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 6, 2022
…esleywiser

Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang#94953

cc: rust-lang#85549

r? ``@wesleywiser``

cc: ``@rust-lang/rustdoc``
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 7, 2022
…esleywiser

Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang#94953

cc: rust-lang#85549

r? ```@wesleywiser```

cc: ```@rust-lang/rustdoc```
@xFrednet xFrednet removed the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label May 7, 2022
bors added a commit to rust-lang-ci/rust that referenced this issue May 9, 2022
…leywiser

Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang#94953

cc: rust-lang#85549

r? `@wesleywiser`

cc: `@rust-lang/rustdoc`
xFrednet pushed a commit to xFrednet/rust-clippy that referenced this issue May 15, 2022
Support tool lints with the `#[expect]` attribute (RFC 2383)

This PR fixes the ICE rust-lang/rust#94953 by making the assert for converted expectation IDs conditional.

Additionally, it moves the lint expectation check into a separate query to support rustdoc and other tools. On the way, I've also added some tests to ensure that the attribute works for Clippy and rustdoc lints.

The number of changes comes from the long test file. This may look like a monster PR, this may smell like a monster PR and this may be a monster PR, but it's a harmless monster. 🦕

---

Closes: rust-lang/rust#94953

cc: rust-lang/rust#85549

r? `@wesleywiser`

cc: `@rust-lang/rustdoc`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jun 4, 2022
…g, r=wesleywiser

Support the `#[expect]` attribute on fn parameters (RFC-2383)

A small PR to allow the `#[expect]` attribute on function parameters.

Nothing more to say, I hope everyone reading this has a lovely day.

---

r? `@wesleywiser`

closes: rust-lang#97650

cc: rust-lang#85549
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jun 4, 2022
…g, r=wesleywiser

Support the `#[expect]` attribute on fn parameters (RFC-2383)

A small PR to allow the `#[expect]` attribute on function parameters.

Nothing more to say, I hope everyone reading this has a lovely day.

---

r? ``@wesleywiser``

closes: rust-lang#97650

cc: rust-lang#85549
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jun 10, 2022
…e-for-expect, r=wesleywiser

Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)

Fixes a small ICE with the `delayed_good_path_bug` check.

---

r? `@wesleywiser`

cc: `@eddyb` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this

closes: rust-lang#95540

cc: rust-lang#85549
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jun 10, 2022
…e-for-expect, r=wesleywiser

Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)

Fixes a small ICE with the `delayed_good_path_bug` check.

---

r? ``@wesleywiser``

cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this

closes: rust-lang#95540

cc: rust-lang#85549
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 16, 2022
…-warn, r=wesleywiser,flip1995

Support lint expectations for `--force-warn` lints (RFC 2383)

Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.

This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.

This will probably conflict with rust-lang#97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.

---

r? `@wesleywiser`

cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃

Follow-up of: rust-lang#87835

Issue: rust-lang#85549

Yeah, and that's it.
calebcartwright pushed a commit to calebcartwright/rustfmt that referenced this issue Jun 23, 2022
…wesleywiser,flip1995

Support lint expectations for `--force-warn` lints (RFC 2383)

Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.

This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.

This will probably conflict with rust-lang/rust#97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.

---

r? `@wesleywiser`

cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃

Follow-up of: rust-lang/rust#87835

Issue: rust-lang/rust#85549

Yeah, and that's it.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 7, 2022
…n-magic, r=wesleywiser

Finishing touches for `#[expect]` (RFC 2383)

This PR adds documentation and some functionality to rustc's lint passes, to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully, it should be one of the last things before we can move forward with stabilizing this feature.

As part of this PR, I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly.

---

changelog: [`duplicate_mod`]: Fixed lint attribute interaction

r? `@wesleywiser`

cc: rust-lang#97660, rust-lang#85549

And I guess that's it. Here have a magical unicorn 🦄
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 7, 2022
…n-magic, r=wesleywiser

Finishing touches for `#[expect]` (RFC 2383)

This PR adds documentation and some functionality to rustc's lint passes, to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully, it should be one of the last things before we can move forward with stabilizing this feature.

As part of this PR, I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly.

---

changelog: [`duplicate_mod`]: Fixed lint attribute interaction

r? ``@wesleywiser``

cc: rust-lang#97660, rust-lang#85549

And I guess that's it. Here have a magical unicorn 🦄
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 7, 2022
…n-magic, r=wesleywiser

Finishing touches for `#[expect]` (RFC 2383)

This PR adds documentation and some functionality to rustc's lint passes, to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully, it should be one of the last things before we can move forward with stabilizing this feature.

As part of this PR, I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly.

---

changelog: [`duplicate_mod`]: Fixed lint attribute interaction

r? ```@wesleywiser```

cc: rust-lang#97660, rust-lang#85549

And I guess that's it. Here have a magical unicorn 🦄
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Jul 7, 2022
…n-magic, r=wesleywiser

Finishing touches for `#[expect]` (RFC 2383)

This PR adds documentation and some functionality to rustc's lint passes, to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully, it should be one of the last things before we can move forward with stabilizing this feature.

As part of this PR, I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly.

---

changelog: [`duplicate_mod`]: Fixed lint attribute interaction

r? `@wesleywiser`

cc: rust-lang#97660, rust-lang#85549

And I guess that's it. Here have a magical unicorn 🦄
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Jul 14, 2022
…r=wesleywiser

Finishing touches for `#[expect]` (RFC 2383)

This PR adds documentation and some functionality to rustc's lint passes, to manually fulfill expectations. This is needed for some lints in Clippy. Hopefully, it should be one of the last things before we can move forward with stabilizing this feature.

As part of this PR, I've also updated `clippy::duplicate_mod` to showcase how this new functionality can be used and to ensure that it works correctly.

---

changelog: [`duplicate_mod`]: Fixed lint attribute interaction

r? `@wesleywiser`

cc: rust-lang/rust#97660, rust-lang/rust#85549

And I guess that's it. Here have a magical unicorn 🦄
@xFrednet
Copy link
Member

I'm closing this, since the feature has been implemented :D

@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Jul 12, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. F-lint_reasons `#![feature(lint_reasons)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants