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

nikomatsakis · 2021-05-21T14:25:24Z

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:

Handle #[expect(unfulfilled_lint_expectations)] -- Improve expect impl and handle #[expect(unfulfilled_lint_expectations)] (RFC 2383) #94670
Update unstable expectation ids in HandlerInner::stashed_diagnostics -- Improve expect impl and handle #[expect(unfulfilled_lint_expectations)] (RFC 2383) #94670
Make #[expect()] work for rustdoc:: lints Support tool lints with the #[expect] attribute (RFC 2383) #95542
ICE: no warnings or errors encountered even though delayed_good_path_bugs issued #![feature(lint_reasons)] #95540
#[expect(..)] not supported on function arguments #97650
Handle --force-warn with expect (Support lint expectations for --force-warn lints (RFC 2383) #97757)
#[expect(...)] doen't catch lints from different check_* function #97660
Make confusable_idents work with #[expect] currently, the lint is emitted and doesn't fulfill the expectation.
Update unstable documentation to reflect this change.

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

The text was updated successfully, but these errors were encountered:

nikomatsakis · 2021-05-21T14:43:55Z

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

Create a feature gate lint_reasons per the directions here
Create some ui tests covering the expected behavior (instructions)
- #[expect(dead_code)] on a dead function, for example
- #[expect(dead_code)] on a live function, for example
- you can add in the incorrect behavior and use --bless and add a FIXME(Implement expect attribute from RFC 2383, "Lint Reasons RFC" #85549) into the test

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 · 2021-05-21T14:44:12Z

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

xFrednet · 2021-05-21T14:59:51Z

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:

Collect all expectations (This can be done by the LintLevelsBuilder or a more specific walker if needed)
Save these expectations in an accessible manner
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
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 · 2021-05-21T15:19:55Z

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 · 2021-05-21T15:27:48Z

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 · 2021-05-21T15:30:18Z

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

xFrednet · 2021-05-21T16:08:37Z

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 · 2021-05-29T10:25:45Z

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:

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

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
It inserts the emitted code into rustc_error::HandlerInner::emitted_diagnostic_codes.insert(code.clone());.
It checks if this specific diagnostic has been emitted before by comparing the hash with rustc_error::HandlerInner::emitted_diagnostics
Then inserts its hash into rustc_error::HandlerInner::emitted_diagnostics
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

Only lints with a level above Allow are even emitted.
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)

…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

…-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 :)

…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`

…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``

…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```

…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`

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`

…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

…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

…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

…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

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

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

…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 🦄

…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 🦄

…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 🦄

…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 🦄

…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 · 2024-06-26T20:15:28Z

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

nikomatsakis · 2024-07-12T14:04:11Z

Huzzah!

…

On Wed, Jun 26, 2024, at 4:15 PM, Fridtjof Stoldt wrote: I'm closing this, since the feature has been implemented :D — Reply to this email directly, view it on GitHub <#85549 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF4ZW5E2VUXSVGZDO6TGLZJMOPPAVCNFSM6AAAAABJ6SRDU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJSGU2DSMBQHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

nikomatsakis mentioned this issue May 21, 2021

Tracking issue for RFC 2383, "Lint Reasons RFC" #54503

Closed

6 tasks

rustbot assigned xFrednet May 21, 2021

xFrednet mentioned this issue Jun 5, 2021

Adding the expect attribute (RFC 2383) #86024

Closed

4 tasks

xFrednet mentioned this issue Aug 7, 2021

Implementation of the expect attribute (RFC 2383) #87835

Merged

xFrednet mentioned this issue Mar 6, 2022

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

Merged

xFrednet added the F-lint_reasons `#![feature(lint_reasons)]` label Mar 6, 2022

xFrednet mentioned this issue Mar 31, 2022

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

Merged

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

This was referenced Jun 3, 2022

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

Merged

Fix delayed_good_path_bug ice for expected diagnostics (RFC 2383) #97718

Merged

xFrednet mentioned this issue Jun 5, 2022

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

Merged

xFrednet mentioned this issue Jun 25, 2022

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

Merged

B14CK313 mentioned this issue May 15, 2024

#[expect(...)] attribute not working for clippy::unsafe_derive_deserialize rust-lang/rust-clippy#12802

Closed

xFrednet closed this as completed Jun 26, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

nikomatsakis commented May 21, 2021 •

edited by xFrednet

Loading

nikomatsakis commented May 21, 2021

nikomatsakis commented May 21, 2021

xFrednet commented May 21, 2021

nikomatsakis commented May 21, 2021

xFrednet commented May 21, 2021

nikomatsakis commented May 21, 2021

xFrednet commented May 21, 2021

xFrednet commented May 29, 2021

Incremental compilation diagnostics

Normal lint emission

`rustc_error::HandlerInner::emit_diagnostic(diag)`

xFrednet commented Jun 26, 2024

nikomatsakis commented Jul 12, 2024 via email

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

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

Comments

nikomatsakis commented May 21, 2021 • edited by xFrednet Loading

nikomatsakis commented May 21, 2021

nikomatsakis commented May 21, 2021

xFrednet commented May 21, 2021

nikomatsakis commented May 21, 2021

xFrednet commented May 21, 2021

nikomatsakis commented May 21, 2021

xFrednet commented May 21, 2021

xFrednet commented May 29, 2021

Details diagnostic emission breakdown

Incremental compilation diagnostics

Normal lint emission

rustc_error::HandlerInner::emit_diagnostic(diag)

Summary

Further steps

xFrednet commented Jun 26, 2024

nikomatsakis commented Jul 12, 2024 via email

nikomatsakis commented May 21, 2021 •

edited by xFrednet

Loading

`rustc_error::HandlerInner::emit_diagnostic(diag)`