traits: Represent live alias arguments as bitsets

[Dnreikronos]

Split out of #160212 per review / Zulip: https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841

live_args_for_alias_from_outlives_bounds and args_known_to_outlive_alias_params now return identity arg indices (DenseBitSet) instead of EarlyBinder<GenericArg>. Callers just do args[idx].visit_with(...), so we stop laundering rigidness through binder instantiate. Also drops the old BitSet FIXME.

imo this is worth doing on its own even without the ICE fix. every time we shoved identity params through EarlyBinder we were writing down something we don't actually know, and this module is only going to grow. better to make the invariant explicit now than keep paying for it later.

No behavioral change intended. the rigid-alias ICE / extract_verify_if_eq bits stay on #160212. btw if that one should stack on this instead of staying independent, lmk and I'll rebase it asap.

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, types
• compiler, types expanded to 75 candidates
• Random selection from 18 candidates

[Dnreikronos]

@lcnr hey, this is the bitset-only split from #160212 / the Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/near/615557841

fyi no matcher / ICE changes here. just arg indices via DenseBitSet, so callers do args[idx] instead of EarlyBinder + instantiate. also kills the BitSet FIXME.

imo this is the boring half and should be easy to land first. the interesting open question (proper matching vs underapproximating in extract_verify_if_eq) stays on #160212. lmk if anything looks off or if you want me to rebase that one on top of this asap.

[panstromek]

@bors try @rust-timer queue

I assume we want to test perf on this, this seems like it could have perf implications.

[rust-bors]

☀️ Try build successful (CI)
Build commit: eb7fea4 (eb7fea435c224921ea27002d0fa50f308f2a2e00)
Base parent: e64c8a6 (e64c8a664d9da54fc239cd4404cbf67f0d624326)

[rust-timer]

Finished benchmarking commit (eb7fea4): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (secondary 2.7%)

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)	5.2%	[0.5%, 12.1%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-0.7%, -0.4%]	3
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -0.2%)

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.9%	[0.5%, 2.3%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.9%	[-1.9%, -0.4%]	13
All ❌✅ (primary)	-	-	0

Binary size

Results (secondary -0.1%)

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)	-0.1%	[-0.2%, -0.0%]	16
All ❌✅ (primary)	-	-	0

Bootstrap: 455.693s -> 454.48s (-0.27%)
Artifact size: 396.39 MiB -> 396.46 MiB (0.02%)

[adwinwhite]

Would it be better to use an index newtype since it's on public API? Unsure it matters much since it's actually only used in the same module.

[lcnr]

Would it be better to use an index newtype since it's on public API? Unsure it matters much since it's actually only used in the same module.

either seems fine to me personally 🤷