Label non_exhaustive attribute on privacy errors from non-local items

[compiler-errors]

Label when an ADT is non_exhaustive and we get a privacy error, help with confusion in a case like this:

#[non_exhaustive]
pub struct Foo;

// other crate
let x = Foo;
//~^ ERROR unit struct `Foo` is private

[rustbot]

r? @WaffleLapkin

(rustbot has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

@bors try @rust-timer queue

I wonder if the extra get_attr here is going to be expensive - hopefully not, but if so maybe we can only do it if all fields are mentioned (or there are no fields), which this code is already mostly doing I suspect?

[bors]

⌛ Trying commit 8ed2dc0 with merge d53a6dffb83447b7ffd6880976ccb09d6112fc33...

[compiler-errors]

Just noting that this only happens in an error reporting function, so I would be very surprised if this affects perf.

[WaffleLapkin]

r=me ig (is there a reason to wait for the perf run?...)

[estebank]

@bors r=WaffleLapkin

Yeah, perf is not gonna show anything given this only happens in the error case.

[bors]

📌 Commit 8ed2dc0 has been approved by WaffleLapkin

It is now in the queue for this repository.

[compiler-errors]

@bors r-

[compiler-errors]

Please don't r+ a pr that is currently <try>ing. That'll make bors auto-merge the PR without any tests or making dist artifacts.

[bors]

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

[bors]

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

[compiler-errors]

now we can r+ this

@bors r=WaffleLapkin

[bors]

📌 Commit 8ed2dc0 has been approved by WaffleLapkin

It is now in the queue for this repository.

[rust-timer]

Finished benchmarking commit (d53a6dffb83447b7ffd6880976ccb09d6112fc33): 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)	3.4%	[3.4%, 3.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.6%	[-2.6%, -2.6%]	1
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	0.4%	[-2.6%, 3.4%]	2

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.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[compiler-errors]

@bors rollup

[estebank]

Please don't r+ a pr that is currently ing. That'll make bors auto-merge the PR without any tests or making dist artifacts.

Ah yeah, I'd forgotten about that :-/