Check assoc consts and tys later like assoc fns

[mu001999]

This PR

1. checks assoc consts and tys later like assoc fns
2. marks assoc consts appear in poly-trait-ref live

For assoc consts, considering

#![deny(dead_code)]

trait Tr { // ERROR trait `Tr` is never used
    const I: Self;
}

struct Foo; //~ ERROR struct `Foo` is never constructed

impl Tr for Foo {
    const I: Self = Foo;
}

fn main() {}

Current this will produce unused I instead of unused Tr and Foo (play), because const I: Self = Foo; will be added into the worklist at first:

error: associated constant `I` is never used
 --> src/main.rs:4:11
  |
3 | trait Tr { // ERROR trait `Tr` is never used
  |       -- associated constant in this trait
4 |     const I: Self;
  |           ^
  |
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(dead_code)]
  |         ^^^^^^^^^

error: could not compile `playground` (bin "playground") due to 1 previous error

This also happens to assoc tys, see the new test

Fixes #126729

r? @petrochenkov

[mu001999]

@rustbot ready

[petrochenkov]

@bors r+

[bors]

📌 Commit 889582e has been approved by petrochenkov

It is now in the queue for this repository.

[Kobzol]

@rust-timer build eca1577

Checking for #143888.

[rust-timer]

Finished benchmarking commit (eca1577): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.1%, 0.8%]	15
Regressions ❌ (secondary)	0.8%	[0.8%, 0.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.1%, 0.8%]	15

Max RSS (memory usage)

Results (primary -0.8%, secondary 4.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.7%, 2.7%]	1
Regressions ❌ (secondary)	4.1%	[4.1%, 4.1%]	1
Improvements ✅ (primary)	-2.5%	[-3.3%, -1.7%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.8%	[-3.3%, 2.7%]	3

Cycles

Results (secondary -4.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.6%	[-5.8%, -3.4%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 465.776s -> 464.957s (-0.18%)
Artifact size: 374.73 MiB -> 374.71 MiB (-0.01%)

[Kobzol]

This PR caused the small perf. regression in #143888. @petrochenkov Do you think there's something to improve here, or do we just eat the regression, since this was a lint improvement?

[petrochenkov]

Associated type resolution can be improved - #143519 (comment).
I think it makes sense to create an issue for storing resolutions for associated type constraints somewhere (if they are not yet stored) instead of doing resolution again and again.

Although I'm not sure this is the source of the regression here.
We are just doing more work for associated types and constants here, and typenum is exactly a crate where that shows.