Remove the `ty` field from type system `Const`s #125958

BoxyUwU · 2024-06-04T06:49:07Z

Part of the work on adt_const_params/generic_const_param_types/min_generic_const_exprs/generally making the compiler nicer. cc rust-lang/project-const-generics#44

Please review commit-by-commit otherwise I wasted a lot of time not just squashing this into a giant mess (and also it'll be SO much nicer because theres a lot of fluff changes mixed in with other more careful changes if looking via File Changes

Why do this?

The ty field keeps causing ICEs and weird behaviour due to it either being treated as "part of the const" or it being forgotten about leading to ICEs.
As we move forward with adt_const_params and a potential min_generic_const_exprs it's going to become more complex to actually lower the correct Ty<'tcx>
It muddles the idea behind how we check Const arguments have the correct type. By having the ty field it may seem like we ought to be relating it when we relate two types, or that its generally important information about the Const.
Brings the compiler more in line with a-mir-formality as that also tracks the type of type system Consts via ConstArgHasType bounds in the env instead of on the Const itself.
A lot of stuff is a lot nicer when you dont have to pass around the type of a const lol. Everywhere we construct Const is now significantly nicer 😅

See #125671's description for some more information about the ty field

General summary of changes in this PR:

Add Ty to ConstKind::Value as otherwise there is no way to implement ConstArgHasType to ensure that const arguments are correctly typed for the parameter when we stop creating anon consts for all const args. It's also just incredibly difficult/annoying to thread the correct Ty around to a bunch of ctfe functions otherwise.
Fully implement ConstArgHasType in both the old and new solver. Since it now has no reliance on the ty field it serves its originally intended purpose of being able to act as a double check that trait vs impls have correctly typed const parameters. It also will now be able to be responsible for checking types of const arguments to parameters under min_generic_const_exprs.
Add Ty to mir::Const::Ty. I dont have a great understanding of why mir constants are setup like this to be honest. Regardless they need to be able to determine the type of the const and the easiest way to make this happen was to simply store the Ty along side the ty::Const. Maybe we can do better here in the future but I'd have to spend way more time looking at everywhere we use mir::Const.
rustdoc has its own Const which also has a ty field. It was relatively easy to remove this.

r? @lcnr @compiler-errors

rustbot · 2024-06-04T06:49:18Z

changes to the core type system

cc @compiler-errors, @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_sanitizers

cc @rust-lang/project-exploit-mitigations, @rcvalle

HIR ty lowering was modified

cc @fmease

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in need_type_info.rs

cc @lcnr

rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing src/librustdoc/json/conversions.rs; otherwise, make sure you bump the FORMAT_VERSION constant.

cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The Miri subtree was changed

cc @rust-lang/miri

changes to the core type system

cc @compiler-errors, @lcnr

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

BoxyUwU · 2024-06-04T06:50:49Z

src/rustdoc-json-types/lib.rs

@@ -8,7 +8,7 @@ use serde::{Deserialize, Serialize};
 use std::path::PathBuf;

 /// rustdoc format-version.
-pub const FORMAT_VERSION: u32 = 29;
+pub const FORMAT_VERSION: u32 = 30;


RalfJung · 2024-06-04T08:03:04Z

SMIR represents mir consts and ty consts using the same Const type. This... does not work at all anymore so I have split them into two different types in SMIR and it seems to make everything a lot nicer regardless of this PR.

Cc rust-lang/project-stable-mir#71

oli-obk

partial review

compiler/rustc_codegen_ssa/src/debuginfo/type_names.rs

compiler/rustc_trait_selection/src/solve/mod.rs

compiler/rustc_trait_selection/src/traits/fulfill.rs

oli-obk · 2024-06-04T08:15:57Z

compiler/rustc_trait_selection/src/traits/fulfill.rs

+                        // FIXME(BoxyUwU): this doesnt seem right
+                        ty::ConstKind::Placeholder(_) => {
+                            return ProcessResult::Changed(mk_pending(vec![]));
                        }


will this just always stall? Is this even reachable? (and why don't we do the same as the new solver and look it up in the param env?

In the new solver we canonicalize ConstKind::Param to ConstKind::Placeholder so we turn param env's with ConstArgHasType(T/#0, usize) into ConstArgHasType(!0, usize) so we will actually have candidate for placeholders. (But we still wont have any in the new solver for higher ranked consts, i.e. for<const N: usize>) after instantiating the binder with placeholders) In the old solver we keep everything as ConstKind::Param.

So both solvers do not handle for<const N: usize> correctly in ConstArgHasType. I meant to check whether this is an issue for some of the wfck stuff of gats which constructs ConstKind::Bound but forgot.

I think also this won't stall it will just succeed (i.e. equivalent Ok(Certainty::Yes) in the new solver)

So I think this is probably unreachable because the only way we should get placeholders in the old solver is via instantiating a binder such as for<const N: usize>. Those are only writeable with the unstable feature(non_lifetime_binders) and that is.... very unstable (i.e. it doesn't really matter if it's a bit broken here). compare_impl_item artificially creates a ParamEnv with for<const N: usize> however since its a ParamEnv we're only ever going to end up instantiating that binder with inference variables. (we dont seem to normalize this env afaict).

I think I should probably just turn this into an unreachable!() so worst case we hit an ICE here instead of unsoundness. But I think its okay... I'd like lcnr to double check my logic here 😅

fmease · 2024-06-04T10:21:01Z

compiler/rustc_hir_analysis/src/hir_ty_lowering/object_safety.rs

-                                c.ty().walk().any(|arg| arg == dummy_self.into())
-                            }
+                            // FIXME(associated_const_equality): We should walk the const instead of not doing anything
+                            ty::TermKind::Const(_) => false,


Yes, indeed. You can leave it as is. I need to work on assoc const items inside trait obj tys anyway. Adding one more FIXME is fine.

I've been meaning to fix trait_object_dummy_self getting leaked via const projections (#123456, #123140, #125957) for a while now (but it's ugly).

lcnr · 2024-06-04T11:18:36Z

compiler/rustc_middle/src/ty/consts/kind.rs

+        Self { kind, args }
+    }
+
+    pub fn args(&self) -> ty::GenericArgsRef<'tcx> {


Suggested change

pub fn args(&self) -> ty::GenericArgsRef<'tcx> {

pub fn args(self) -> ty::GenericArgsRef<'tcx> {

may resolve in a later PR, but why is that a method instead of just accessing the field?

originally I just didnt want to give access to the args since they're always in a specific format and the GenericArgsRef loses that information. turned out I needed it for structurally_relate_tys and now I just sort of kept it because all the other ways of accessing the args go through a method so,,

compiler/rustc_middle/src/ty/consts/kind.rs

compiler/rustc_ty_utils/src/consts.rs

compiler/rustc_middle/src/ty/relate.rs

compiler/rustc_hir_typeck/src/pat.rs

lcnr · 2024-06-04T11:41:15Z

compiler/rustc_middle/src/ty/consts.rs

@@ -311,7 +307,7 @@ impl<'tcx> Const<'tcx> {
        tcx: TyCtxt<'tcx>,
        param_env: ParamEnv<'tcx>,
        span: Span,
-    ) -> Result<ValTree<'tcx>, ErrorHandled> {
+    ) -> Result<(Ty<'tcx>, ValTree<'tcx>), ErrorHandled> {


Suggested change

) -> Result<(Ty<'tcx>, ValTree<'tcx>), ErrorHandled> {

) -> Result<(ValTree<'tcx>, Ty<'tcx>)>, ErrorHandled>

or tbh, maybe add

struct ConstValue { data: ValTree<'tcx>, ty: Ty<'tcx>, }

would be open to leave that for a separate PR though, we should merge this fairly quickly as it's quite prone to merge conflicts

nods will follow up with this

Remove the `ty` field from type system `Const`s Fixes rust-lang#125556 Fixes rust-lang#122908 Part of the work on `adt_const_params`/`generic_const_param_types`/`min_generic_const_exprs`/generally making the compiler nicer. cc rust-lang/project-const-generics#44 Please review commit-by-commit otherwise I wasted a lot of time not just squashing this into a giant mess (and also it'll be SO much nicer because theres a lot of fluff changes mixed in with other more careful changes if looking via File Changes --- Why do this? - The `ty` field keeps causing ICEs and weird behaviour due to it either being treated as "part of the const" or it being forgotten about leading to ICEs. - As we move forward with `adt_const_params` and a potential `min_generic_const_exprs` it's going to become more complex to actually lower the correct `Ty<'tcx>` - It muddles the idea behind how we check `Const` arguments have the correct type. By having the `ty` field it may seem like we ought to be relating it when we relate two types, or that its generally important information about the `Const`. - Brings the compiler more in line with `a-mir-formality` as that also tracks the type of type system `Const`s via `ConstArgHasType` bounds in the env instead of on the `Const` itself. - A lot of stuff is a lot nicer when you dont have to pass around the type of a const lol. Everywhere we construct `Const` is now significantly nicer 😅 See rust-lang#125671's description for some more information about the `ty` field --- General summary of changes in this PR: - Add `Ty` to `ConstKind::Value` as otherwise there is no way to implement `ConstArgHasType` to ensure that const arguments are correctly typed for the parameter when we stop creating anon consts for all const args. It's also just incredibly difficult/annoying to thread the correct `Ty` around to a bunch of ctfe functions otherwise. - Fully implement `ConstArgHasType` in both the old and new solver. Since it now has no reliance on the `ty` field it serves its originally intended purpose of being able to act as a double check that trait vs impls have correctly typed const parameters. It also will now be able to be responsible for checking types of const arguments to parameters under `min_generic_const_exprs`. - Add `Ty` to `mir::Const::Ty`. I dont have a great understanding of why mir constants are setup like this to be honest. Regardless they need to be able to determine the type of the const and the easiest way to make this happen was to simply store the `Ty` along side the `ty::Const`. Maybe we can do better here in the future but I'd have to spend way more time looking at everywhere we use `mir::Const`. - rustdoc has its own `Const` which also has a `ty` field. It was relatively easy to remove this. --- r? `@lcnr` `@compiler-errors`

bors · 2024-06-06T01:26:32Z

⌛ Testing commit 3a6b606 with merge e3c8bd5...

rust-log-analyzer · 2024-06-06T01:31:34Z

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

  Python2_ROOT_DIR: /Users/runner/hostedtoolcache/Python/3.12.3/x64
  Python3_ROOT_DIR: /Users/runner/hostedtoolcache/Python/3.12.3/x64
##[endgroup]
curl: (28) Operation too slow. Less than 100 bytes/sec transferred the last 5 seconds
Error: Failure while executing; `/usr/bin/env /usr/local/Homebrew/Library/Homebrew/shims/shared/curl --disable --cookie /dev/null --globoff --user-agent Homebrew/4.3.1\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.6.7\)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --remote-time --output /Users/runner/Library/Caches/Homebrew/api/formula.jws.json --location --disable --cookie /dev/null --globoff --show-error --user-agent Homebrew/4.3.1\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.6.7\)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --compressed --speed-limit 100 --speed-time 5 https://formulae.brew.sh/api/formula.jws.json` exited with 28. Here's the output:
##[error]Failure while executing; `/usr/bin/env /usr/local/Homebrew/Library/Homebrew/shims/shared/curl --disable --cookie /dev/null --globoff --user-agent Homebrew/4.3.1\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.6.7\)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --remote-time --output /Users/runner/Library/Caches/Homebrew/api/formula.jws.json --location --disable --cookie /dev/null --globoff --show-error --user-agent Homebrew/4.3.1\ \(Macintosh\;\ Intel\ Mac\ OS\ X\ 13.6.7\)\ curl/8.4.0 --header Accept-Language:\ en --fail --progress-bar --silent --compressed --speed-limit 100 --speed-time 5 https://formulae.brew.sh/api/formula.jws.json` exited with 28. Here's the output:
curl: (28) Operation too slow. Less than 100 bytes/sec transferred the last 5 seconds

##[error]Process completed with exit code 1.
Post job cleanup.

bors · 2024-06-06T01:32:07Z

💔 Test failed - checks-actions

workingjubilee · 2024-06-06T02:12:19Z

@bors retry

bors · 2024-06-06T03:41:27Z

⌛ Testing commit 3a6b606 with merge 003a902...

bors · 2024-06-06T05:54:59Z

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 003a902 to master...

rust-timer · 2024-06-06T07:10:31Z

Finished benchmarking commit (003a902): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-0.6%, -0.3%]	3
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.2%)

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)	2.2%	[1.0%, 3.4%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.2%	[1.0%, 3.4%]	2

Cycles

Results (secondary 3.5%)

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

Binary size

Results (primary 0.1%)

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

Bootstrap: 669.842s -> 668.946s (-0.13%)
Artifact size: 319.03 MiB -> 319.07 MiB (0.01%)

Stall dropaStall computing instance for drop shim until it has no unsubstituted const params Stall resolving the drop shim instance for types that still have unsubstituted const params. ## Why? rust-lang#127030 ICEs because it tries to inline the drop shim for a type with an unsubstituted const param. In order to generate this shim, this requires calling the drop shim builder, which invokes the trait solver to compute whether constituent types need drop (since we compute if a type is copy to disqualify any `Drop` behavior): https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_dataflow/src/elaborate_drops.rs#L378 However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env: https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_transform/src/shim.rs#L278 (which is the param-env of `std::ptr::drop_in_place`) This param-env is notably missing `ConstParamHasTy` predicates, and since we removed the type from consts in rust-lang#125958, we literally cannot prove these predicates in this (relatively) empty param-env. This currently happens in places like the MIR inliner, but may happen elsewhere such as in lints that resolve terminators. ## What? We delay the resolution (`Instance::resolve`) of calls for `drop_in_place` for types that have unsubstituted const params. This should be OK, since all cases that deal with polymorphic code should handle `Instance::resolve` returning `None` gracefully.

Stall computing instance for drop shim until it has no unsubstituted const params Do not inline the drop shim for types that still have unsubstituted const params. ## Why? rust-lang#127030 ICEs because it tries to inline the drop shim for a type with an unsubstituted const param. In order to generate this shim, this requires calling the drop shim builder, which invokes the trait solver to compute whether constituent types need drop (since we compute if a type is copy to disqualify any `Drop` behavior): https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_dataflow/src/elaborate_drops.rs#L378 However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env: https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_transform/src/shim.rs#L278 (which is the param-env of `std::ptr::drop_in_place`) This param-env is notably missing `ConstParamHasTy` predicates, and since we removed the type from consts in rust-lang#125958, we literally cannot prove these predicates in this (relatively) empty param-env. This currently happens in places like the MIR inliner, but may happen elsewhere such as in lints that resolve terminators. ## What? We force the inliner to not consider calls for `drop_in_place` for types that have unsubstituted const params. ## So what? This may negatively affect MIR inlining, but I doubt this matters in practice, and fixes a beta regression, so let's fix it. I will look into approaches for fixing this in a more maintainable way, perhaps delaying the creation of drop shim bodies until codegen (like how intrinsics work).

Rollup merge of rust-lang#127068 - compiler-errors:stall-drop, r=BoxyUwU Stall computing instance for drop shim until it has no unsubstituted const params Do not inline the drop shim for types that still have unsubstituted const params. ## Why? rust-lang#127030 ICEs because it tries to inline the drop shim for a type with an unsubstituted const param. In order to generate this shim, this requires calling the drop shim builder, which invokes the trait solver to compute whether constituent types need drop (since we compute if a type is copy to disqualify any `Drop` behavior): https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_dataflow/src/elaborate_drops.rs#L378 However, since we don't keep the param-env of the instance we resolved the item for, we use the wrong param-env: https://github.com/rust-lang/rust/blob/9c3bc805dd9cb84019c124b9a50fdff1e62a7ec9/compiler/rustc_mir_transform/src/shim.rs#L278 (which is the param-env of `std::ptr::drop_in_place`) This param-env is notably missing `ConstParamHasTy` predicates, and since we removed the type from consts in rust-lang#125958, we literally cannot prove these predicates in this (relatively) empty param-env. This currently happens in places like the MIR inliner, but may happen elsewhere such as in lints that resolve terminators. ## What? We force the inliner to not consider calls for `drop_in_place` for types that have unsubstituted const params. ## So what? This may negatively affect MIR inlining, but I doubt this matters in practice, and fixes a beta regression, so let's fix it. I will look into approaches for fixing this in a more maintainable way, perhaps delaying the creation of drop shim bodies until codegen (like how intrinsics work).

BoxyUwU added the A-const-generics Area: const generics (parameters and arguments) label Jun 4, 2024

rustbot assigned lcnr Jun 4, 2024

BoxyUwU commented Jun 4, 2024

View reviewed changes

BoxyUwU changed the title ~~Remove the ty field from Const~~ Remove the ty field from type system Consts Jun 4, 2024

oli-obk self-assigned this Jun 4, 2024

This comment has been minimized.

Sign in to view

BoxyUwU force-pushed the remove_const_ty branch from f5b0e54 to 9795611 Compare June 4, 2024 07:18

This comment has been minimized.

Sign in to view

BoxyUwU force-pushed the remove_const_ty branch from 9795611 to f1a5cc0 Compare June 4, 2024 07:46

This comment has been minimized.

Sign in to view

oli-obk requested changes Jun 4, 2024

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2024

BoxyUwU force-pushed the remove_const_ty branch 2 times, most recently from 42e1789 to 0946460 Compare June 4, 2024 09:08

This was referenced Jun 4, 2024

Split smir Const into TyConst and MirConst #125967

Merged

Store the types of ty::Expr arguments in the ty::Expr #125968

Merged

BoxyUwU force-pushed the remove_const_ty branch from 0946460 to 71f4e0c Compare June 4, 2024 09:42

This comment has been minimized.

Sign in to view

fmease reviewed Jun 4, 2024

View reviewed changes

lcnr reviewed Jun 4, 2024

View reviewed changes

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 6, 2024

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 6, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 6, 2024

bors merged commit 003a902 into rust-lang:master Jun 6, 2024
7 checks passed

rustbot added this to the 1.80.0 milestone Jun 6, 2024

workingjubilee mentioned this pull request Jun 6, 2024

Buggy debuginfo test suite, or just function-names.rs? #126060

Open

Enselic mentioned this pull request Jun 7, 2024

Support nightly-2024-06-07 cargo-public-api/cargo-public-api#581

Merged

This was referenced Jun 8, 2024

ICE: None in compiler/rustc_middle/src/ty/sty.rs #126147

Closed

ICE: Failed to normalize std::ops::ControlFlow<Alias(Projection, …), Alias(Projection, …)> #126148

Closed

GrigorenkoPV mentioned this pull request Jun 24, 2024

ICE: None in compiler/rustc_middle/src/ty/sty.rs without feature(effects) #126889

Closed

Nadrieril mentioned this pull request Jun 26, 2024

Update rustc all at once hacspec/hax#735

Merged

lqd mentioned this pull request Jun 27, 2024

nightly ICE when building flexstr in release mode #127030

Closed

compiler-errors mentioned this pull request Jun 28, 2024

Stall computing instance for drop shim until it has no unsubstituted const params #127068

Merged

This was referenced Aug 16, 2024

ICE: None in compiler/rustc_middle/src/ty/sty.rs #129145

Closed

ICE: None in compiler/rustc_middle/src/ty/sty.rs #129209

Open

jean-airoldie mentioned this pull request Sep 2, 2024

[ICE]: None in compiler/rustc_middle/src/ty/sty.rs #129882

Open

4 tasks

aDotInTheVoid mentioned this pull request Sep 22, 2024

Move rustdoc-types crate to T-Rustdoc ownership. rust-lang/rfcs#3505

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove the `ty` field from type system `Const`s #125958

Remove the `ty` field from type system `Const`s #125958

BoxyUwU commented Jun 4, 2024 •

edited

Loading

rustbot commented Jun 4, 2024

BoxyUwU Jun 4, 2024

This comment has been minimized.

This comment has been minimized.

RalfJung commented Jun 4, 2024

This comment has been minimized.

oli-obk left a comment

oli-obk Jun 4, 2024

BoxyUwU Jun 4, 2024 •

edited

Loading

BoxyUwU Jun 4, 2024

BoxyUwU Jun 4, 2024 •

edited

Loading

This comment has been minimized.

fmease Jun 4, 2024 •

edited

Loading

lcnr Jun 4, 2024 •

edited

Loading

BoxyUwU Jun 4, 2024

lcnr Jun 4, 2024

BoxyUwU Jun 4, 2024

bors commented Jun 6, 2024

rust-log-analyzer commented Jun 6, 2024

bors commented Jun 6, 2024

workingjubilee commented Jun 6, 2024

bors commented Jun 6, 2024

bors commented Jun 6, 2024

rust-timer commented Jun 6, 2024

	pub fn args(&self) -> ty::GenericArgsRef<'tcx> {
	pub fn args(self) -> ty::GenericArgsRef<'tcx> {

	) -> Result<(Ty<'tcx>, ValTree<'tcx>), ErrorHandled> {
	) -> Result<(ValTree<'tcx>, Ty<'tcx>)>, ErrorHandled>

Remove the ty field from type system Consts #125958

Remove the ty field from type system Consts #125958

Conversation

BoxyUwU commented Jun 4, 2024 • edited Loading

rustbot commented Jun 4, 2024

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

RalfJung commented Jun 4, 2024

This comment has been minimized.

oli-obk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BoxyUwU Jun 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BoxyUwU Jun 4, 2024 • edited Loading

Choose a reason for hiding this comment

This comment has been minimized.

fmease Jun 4, 2024 • edited Loading

Choose a reason for hiding this comment

lcnr Jun 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Jun 6, 2024

rust-log-analyzer commented Jun 6, 2024

bors commented Jun 6, 2024

workingjubilee commented Jun 6, 2024

bors commented Jun 6, 2024

bors commented Jun 6, 2024

rust-timer commented Jun 6, 2024

Overall result: ✅ improvements - no action needed

Remove the `ty` field from type system `Const`s #125958

Remove the `ty` field from type system `Const`s #125958

BoxyUwU commented Jun 4, 2024 •

edited

Loading

BoxyUwU Jun 4, 2024 •

edited

Loading

BoxyUwU Jun 4, 2024 •

edited

Loading

fmease Jun 4, 2024 •

edited

Loading

lcnr Jun 4, 2024 •

edited

Loading