Report all lints, even if other errors already occurred.

[oli-obk]

This reduces surprises of the "I fixed all the errors, now I'm getting new ones"-kind

r? @ghost

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit c913bdc2672f0ae9f8a8b18d71171129234b1d53 with merge d9845989f7fe27114bf2d89955cc4fa6bade7a67...

[bors]

☀️ Try build successful - checks-actions
Build commit: d9845989f7fe27114bf2d89955cc4fa6bade7a67 (d9845989f7fe27114bf2d89955cc4fa6bade7a67)

[bors]

☀️ Try build successful - checks-actions
Build commit: d9845989f7fe27114bf2d89955cc4fa6bade7a67 (d9845989f7fe27114bf2d89955cc4fa6bade7a67)

[rust-timer]

Finished benchmarking commit (d9845989f7fe27114bf2d89955cc4fa6bade7a67): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.7%	[2.7%, 2.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[oli-obk]

Okay... not sure why I ran perf at all 😃 it's not like perf benchmarks emit errors 🤦

[matthiaskrgr]

Well it kind makes sense to have some warning/error related benchmarks (perhaps even clippy lints 📎 ? )
I have seen code where rustc would print a couple of initial errors, and then "freeze" for a couple of seconds (4-10?) just to not print any further errors which always seemed a bit weird 🙃

[oli-obk]

r? compiler

Will bless the test later today

[lcnr]

how likely is it that we report lints which are invalid because of a previous error? Currently slightly overwhelmed with my other reviews, so

r? compiler

[oli-obk]

how likely is it that we report lints which are invalid because of a previous error?

We should fix those lints by checking for error types or errored typeck in case that happens. I found no obviously wrong cases in the changed diagnostics

[cjgillot]

Type checking errors still early-exit because of the ? on rustc_hir_analysis::check_crate a few lines above.
Removing all the short-circuits in that function open floodgates of a larger magnitude.

[bors]

☔ The latest upstream changes (presumably #108471) made this pull request unmergeable. Please resolve the merge conflicts.

[riking]

This lint is clearly incorrect here: needs an bail for pointer to Err?

[oli-obk]

It's not incorrect, but the wording can use some improvements. Basically only raw pointers that are just integers with a raw pointer type are allowed. All other raw pointers are forbidden.

[rustbot]

These commits modify the Cargo.lock file. Random changes to Cargo.lock can be introduced when switching branches and rebasing PRs.
This was probably unintentional and should be reverted before this PR is merged.

If this was intentional then you can ignore this comment.

[bors]

☔ The latest upstream changes (presumably #108504) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

@oli-obk what's the status on this? do you want me to review it, or is does it need reworking? does it need an FCP? 🤔

[oli-obk]

I guess I could rebase it and then compiler FCP it. Not sure it needs an FCP, i'll bring it up in the T-compiler triage

[wesleywiser]

I think either an FCP or MCP would be fine 🙂

[jyn514]

I think this is a good idea and would second an MCP.

[apiraino]

switching review flag to note that an MCP would be fine in this case (Zulip mention)

@rustbot author

[bors]

☔ The latest upstream changes (presumably #111639) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

@oli-obk
ping from triage - can you post your status on this PR? There hasn't been an update in a few months, and I see a few merge conflicts Thanks!

[WaffleLapkin]

@JohnCSimon Oli is currently on leave, I think they'll continue working on this once they are back in January =)

[oli-obk]

The MCP has not been approved and has concerns that can only be resolved by a larger discussion (RFC?) about whether we want to report all lints and errors upfront, or do it in a phased system like we do now.