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

xFrednet · 2022-03-06T13:39:48Z

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 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 #87835. You are welcome to reassign it if you're busy 🙃

rfc: RFC-2383

tracking issue: #85549

cc: @flip1995 In case you're also interested in this :)

flip1995

I'm still a bit concerned about the assumption that is made here, that unfulfilled_lint_expectations is not in a lint group. This is not statically enforced and might lead to surprising breakages in the future. Can we somehow add a test for this?

I assume warnings is not a real lint group, right? Otherwise the changes in this PR could already fail with that.

compiler/rustc_lint/src/levels.rs

xFrednet · 2022-03-07T16:08:21Z

Very good suggestions, thank you for the review!

I'm still a bit concerned about the assumption that is made here, that unfulfilled_lint_expectations is not in a lint group. This is not statically enforced and might lead to surprising breakages in the future. Can we somehow add a test for this?

I'm not sure how this can be tested. The current implementation doesn't break when a lint group includes the unfulfilled_lint_expectation lint (like warnings), instead it ignores it. I don't think that we need to put much more effort into this, as long as it doesn't ICE or break anything else.

I assume warnings is not a real lint group, right? Otherwise the changes in this PR could already fail with that.

I've added a test with #[expect(warnings)]. The attribute would emit a lint message for a missing lint. However, it also suppresses the created lint message and is therefore silent. I think that this is a reasonable solution.

I've rebased and addressed your feedback 🙃

flip1995

I'm not sure how this can be tested.

Me neither. The only thing, that could be done would be to use ids.iter().find(..) to make sure that this doesn't happen. But this might have a performance impact and is in the current state unnecessary, because the unfulfilled_lint_expectations lint is currently not in a group.

Maybe I'm overthinking this. I mean it is really unlikely that this lint will ever get added to a group.

flip1995 · 2022-03-08T08:35:31Z

src/test/ui/lint/rfc-2383-lint-reason/expect_unfulfilled_expectation.rs

+#[expect(warnings, reason = "this suppresses all warnings and also suppresses itself. No warning will be issued")]
+pub fn expect_warnings() {
+    // This lint trigger will be suppressed
+    #[warn(unused_mut)]


I just wondered why this doesn't warn here. It should override theexpect/allow of the outer scope. But it seems like warnings is somehow treated differently to other lint groups. It behaves the same as with allow, see Playground, so this is not a bug in the expect attribute.

But I would argue, that this is generally surprising behavior. Is this documented somewhere?

Yes, the warnings name seems to behave a bit differently. It looks like it sets the level for all warnings in a given scope. I only could find this documentation:

source and this. But both say that it behaves like a lint group and not overrides the level. I think this is fine for now as it behaves like the allow attribute 🙃

I think this is fine for now

Agreed. Nothing to do in this PR. I just wanted to point out this behavior, because I thought it is generally unexpected/surprising.

flip1995

With the added comment, this LGTM. I'll let @wesleywiser give this another look, but after that r=me.

compiler/rustc_lint/src/levels.rs

… (RFC 2383)

wesleywiser · 2022-03-14T14:17:06Z

compiler/rustc_lint/src/levels.rs

+                        // This checks for instances where the user writes `#[expect(unfulfilled_lint_expectations)]`
+                        // in that case we want to avoid overriding the lint level but instead add an expectation that
+                        // can't be fulfilled. The lint message will include an explanation, that the
+                        // `unfulfilled_lint_expectations` lint can't be expected.


This behavior makes sense to me (as we discussed in the last PR) but before stabilization, we should decide if this is the correct approach. After stabilization, changing the behavior here will be potentially breaking. If we make this a hard error, then we can always relax that later backwards-compatibly.

wesleywiser · 2022-03-14T14:19:12Z

@bors r=flip1995,wesleywiser

bors · 2022-03-14T14:19:13Z

📌 Commit be84049 has been approved by flip1995,wesleywiser

…askrgr Rollup of 5 pull requests Successful merges: - rust-lang#90621 (Stabilise `aarch64_target_feature`) - rust-lang#93977 (Type params and assoc types have unit metadata if they are sized) - rust-lang#94670 (Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383)) - rust-lang#94884 (Fix remaining meta-variable expression TODOs) - rust-lang#94931 (update miri) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

xFrednet added A-diagnostics Area: Messages for errors, warnings, and lints T-lang Relevant to the language team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2022

rust-highfive assigned wesleywiser Mar 6, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 6, 2022

This comment has been minimized.

Sign in to view

xFrednet force-pushed the rfc-2383-expect-impl-after-party branch from 2ae4720 to e97c9fc Compare March 6, 2022 13:54

xFrednet mentioned this pull request Mar 6, 2022

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

Closed

9 tasks

flip1995 reviewed Mar 7, 2022

View reviewed changes

xFrednet added 2 commits March 7, 2022 18:08

Update unstable ExpectationIds in stored diagnostics

47f3f66

Fix typos in LintExpectationId docs

165b558

xFrednet force-pushed the rfc-2383-expect-impl-after-party branch 2 times, most recently from 76d97de to 16b7fbf Compare March 7, 2022 18:58

Handle #[expect(unfulfilled_lint_expectations)] with a lint message

d39d609

xFrednet force-pushed the rfc-2383-expect-impl-after-party branch from 16b7fbf to d39d609 Compare March 7, 2022 18:59

flip1995 reviewed Mar 8, 2022

View reviewed changes

flip1995 approved these changes Mar 9, 2022

View reviewed changes

compiler/rustc_lint/src/levels.rs Show resolved Hide resolved

Add comment about unfulfilled_lint_expectation not being in a group…

be84049

… (RFC 2383)

wesleywiser approved these changes Mar 14, 2022

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 14, 2022

matthiaskrgr mentioned this pull request Mar 14, 2022

Rollup of 5 pull requests #94935

Merged

bors merged commit 6548a36 into rust-lang:master Mar 15, 2022

rustbot added this to the 1.61.0 milestone Mar 15, 2022

matthiaskrgr mentioned this pull request Mar 15, 2022

ICE: all diagnostics with unstable expectations should have been converted, compiler/rustc_errors/src/lib.rs: Zunpretty=expanded #94953

Closed

xFrednet deleted the rfc-2383-expect-impl-after-party branch March 15, 2022 08:46

xFrednet mentioned this pull request Mar 15, 2022

Remove assert for unstable expectation IDs #94968

Closed

xFrednet mentioned this pull request Jul 10, 2022

Document new #[expect] attribute and reasons parameter (RFC 2383) rust-lang/reference#1237

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

xFrednet commented Mar 6, 2022

This comment has been minimized.

flip1995 left a comment

xFrednet commented Mar 7, 2022 •

edited

Loading

flip1995 left a comment

flip1995 Mar 8, 2022

xFrednet Mar 8, 2022

flip1995 Mar 9, 2022 •

edited

Loading

flip1995 left a comment

wesleywiser Mar 14, 2022

wesleywiser commented Mar 14, 2022

bors commented Mar 14, 2022

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

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

Conversation

xFrednet commented Mar 6, 2022

This comment has been minimized.

flip1995 left a comment

Choose a reason for hiding this comment

xFrednet commented Mar 7, 2022 • edited Loading

flip1995 left a comment

Choose a reason for hiding this comment

flip1995 Mar 8, 2022

Choose a reason for hiding this comment

xFrednet Mar 8, 2022

Choose a reason for hiding this comment

flip1995 Mar 9, 2022 • edited Loading

Choose a reason for hiding this comment

flip1995 left a comment

Choose a reason for hiding this comment

wesleywiser Mar 14, 2022

Choose a reason for hiding this comment

wesleywiser commented Mar 14, 2022

bors commented Mar 14, 2022

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

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

xFrednet commented Mar 7, 2022 •

edited

Loading

flip1995 Mar 9, 2022 •

edited

Loading