Remove Const::ty and Const::kind in favor of field accesses via Deref

[oli-obk]

cc @nnethercote

also rename ConstS to ConstData as a) I don't know what the S postfix means b) the *Data naming is what I use for the effects, too and c) rust-analyzer also uses ConstData for the same datastructure

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon.

Please see the contribution instructions for more information.

[rustbot]

Some changes occurred in need_type_info.rs

cc @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in const_evaluatable.rs

cc @lcnr

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[Noratrieb]

TyS uses the same naming and I think consts and tys should be consistent here (I have no idea what S means either so I would prefer seeing a TyData as well :D)

[fmease]

I think the S suffix stands for structure in the sense that Ty (etc.) is the pointer and TyS is the underlying structure. But yea, Data is definitely the way to go

[oli-obk]

TyS uses the same naming and I think consts and tys should be consistent here (I have no idea what S means either so I would prefer seeing a TyData as well :D)

yea, the Ty data structures are on my list as well. Once this PR is merged I'll tackle them.

[oli-obk]

Hey, so I just removed TyS without a loss in usability or anything else: #104898

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit f647045 with merge 0d98fecdb93008583f0446838c452782a71a2dc0...

[bors]

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

[rust-timer]

Finished benchmarking commit (0d98fecdb93008583f0446838c452782a71a2dc0): comparison URL.

Overall result: ❌ regressions - 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-review -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

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.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-2.7%, -2.2%]	2
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)	5.0%	[4.6%, 5.4%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

[jackh726]

This is opposite to the direction we were trying to go for librarification. In Chalk, for example, we deal with interned things behind associated types on Interner, so accessing the data needs to go through the Interner.

[oli-obk]

This is opposite to the direction we were trying to go for librarification. In Chalk, for example, we deal with interned things behind associated types on Interner, so accessing the data needs to go through the Interner.

I thought we only needed that for Ty::kind and this was an accidental way to do the same.

That said, why can't we also use deref for chalk to get the assoc type?

[eddyb]

That said, why can't we also use deref for chalk to get the assoc type?

If your interner uses indices. However, I don't understand why the syntax there isn't e.g. tcx[ty].kind (like how I've done this in my own interners-with-indices projects).