mGCA: Validate const literal against expected type by reddevilmidzy · Pull Request #152001 · rust-lang/rust

reddevilmidzy · 2026-02-02T16:10:33Z

todo

Increasing lit_to_const method test coverage

tests/ui/const-generics/mgca/literal-type-mismatch.rs

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

BoxyUwU · 2026-02-04T12:44:13Z

very cool :) thanks for working on this

…=oli-obk Dont strip const blocks in array lengths r? oli-obk mGCA now handles const blocks by *always* handling them during `lower_expr_to_const_arg_direct` instead of *sometimes* stripping them out at parse time. This is just generally a lot clearer/nicer but also means parsing isn't lossy which is just straight up wrong. We now use `MgcaDisambiguation::Direct` for const blocks because we "directly" represent a const block as `hir::ConstArgKind::Anon` :> The only time that an anon const for const generics uses `MgcaDisambiguation::AnonConst` is for unbraced literals. Once we properly support literals in `hir::ConstArgKind` (see rust-lang#152139 rust-lang#152001) then `MgcaDisambiguation` can be renamed to `AnonConstKind` with `TypeSystem` and `NonTypeSystem` variants. We can also get rid of `mgca_direct_lit_hack`. I expect this to be a very nice cleanup :) Fixes rust-lang/rustfmt#6788 The diff relating to passing spans around is to avoid a bunch of mGCA diagnostics changing from `const {}` to `{}`. I'm not entirely sure why this was happening. cc @rust-lang/rustfmt How do I run the tests in the rustfmt repo from here? `x test rustfmt` only seems to run like 100 tests and doesn't result in a `target/issue-6788.rs` getting created. I've verified locally that this formats correctly though

Rollup merge of #152234 - BoxyUwU:dont_strip_const_blocks, r=oli-obk Dont strip const blocks in array lengths r? oli-obk mGCA now handles const blocks by *always* handling them during `lower_expr_to_const_arg_direct` instead of *sometimes* stripping them out at parse time. This is just generally a lot clearer/nicer but also means parsing isn't lossy which is just straight up wrong. We now use `MgcaDisambiguation::Direct` for const blocks because we "directly" represent a const block as `hir::ConstArgKind::Anon` :> The only time that an anon const for const generics uses `MgcaDisambiguation::AnonConst` is for unbraced literals. Once we properly support literals in `hir::ConstArgKind` (see #152139 #152001) then `MgcaDisambiguation` can be renamed to `AnonConstKind` with `TypeSystem` and `NonTypeSystem` variants. We can also get rid of `mgca_direct_lit_hack`. I expect this to be a very nice cleanup :) Fixes rust-lang/rustfmt#6788 The diff relating to passing spans around is to avoid a bunch of mGCA diagnostics changing from `const {}` to `{}`. I'm not entirely sure why this was happening. cc @rust-lang/rustfmt How do I run the tests in the rustfmt repo from here? `x test rustfmt` only seems to run like 100 tests and doesn't result in a `target/issue-6788.rs` getting created. I've verified locally that this formats correctly though

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

compiler/rustc_mir_build/src/thir/constant.rs

reddevilmidzy · 2026-02-07T12:19:39Z

Haha, ICE occurs in other tests...

reddevilmidzy

Thanks for your quick review. 😊

View changes since this review

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

tests/ui/const-generics/mgca/type_const-mismatched-types.rs

reddevilmidzy

In ten crash tests, the ICE disappeared; however, in ‎tests/crashes/117460.rs, tests/crashes/114212-2.rs and tests/crashes/114212.rs, adding the main function caused the ICE to occur again.

View changes since this review

reddevilmidzy · 2026-02-08T09:12:14Z

tests/ui/const-generics/generic_const_exprs/enum-const-generic-default-param.rs

@@ -0,0 +1,23 @@
+//! Regression test for <https://github.com/rust-lang/rust/issues/116554>


This issue was closed; is there a need to add further testing?

unsure, I will look over all the GCE tests (outside of this PR) at some point soon and see which ones are worth keeping

reddevilmidzy · 2026-02-08T09:18:55Z

tests/crashes/101036.rs

@@ -1,14 +0,0 @@
-//@ known-bug: #101036
-#![feature(generic_const_exprs)]
-


#101036 was a duplicate of #119824.

reddevilmidzy · 2026-02-08T09:35:23Z

Could the following issues also be closed? 🤔

#119824
#133966
#136416

already closed
#94846
#106473
#116554

Co-authored-by: Boxy <rust@boxyuwu.dev>

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

BoxyUwU · 2026-02-08T17:16:36Z

compiler/rustc_mir_build/src/thir/constant.rs

            let str_bytes = s.as_str().as_bytes();
-            ty::ValTree::from_raw_bytes(tcx, str_bytes)
-        }
-        (ast::LitKind::Str(s, _), ty::Str) if tcx.features().deref_patterns() => {


you've deleted the logic here for string literals being of type str under deref_patterns. I don't know why there's no test that cares about this though 🤔

The existing (ast::LitKind::Str(s, _), ty::Ref(_, inner_ty, _)) if inner_ty.is_str() and (ast::LitKind::Str(s, _), ty::Str) if tcx.features().deref_patterns() had identical processing logic, so I've enabled both patterns to be handled as (ast::LitKind::Str(s, _), _) !

Hmm yeah you're right about the actual ValTree structure 🤔 I think there is a behaviour difference now though. Previously if there was an expected type of str the valtree's type would be str whereas now its always &str.

If that doesn't actually affect anything in practice then I guess we should just... always have the &str type and then maybe one day when it breaks something we can get a test

BoxyUwU · 2026-02-08T17:20:24Z

compiler/rustc_mir_build/src/thir/constant.rs

+            (ty::ValTree::from_scalar_int(tcx, scalar_int), Ty::new_uint(tcx, ui))
+        }
+        (ast::LitKind::Int(_, ast::LitIntType::Unsigned(_)), _) if neg => return None,
+        (ast::LitKind::Int(n, ast::LitIntType::Signed(i)), _) => {


you can merge the branches for unsuffixed with type hint, and suffixed with OR patterns:

Suggested change

(ast::LitKind::Int(n, ast::LitIntType::Signed(i)), _) => {

(ast::LitKind::Int(n, ast::LitIntoType::Unsuffixed), ty::Int(i))

| (ast::LitKind::Int(n, ast::LitIntType::Signed(i)), _) => {

can do the same for handling of unsuffixed vs unsigned too

I tried the code you suggested, but it failed to compile because each type was different. 😢

I'll see if I can handle this with a more fancy pattern.

ah if that pattern doesn't "just work" then it seems fine to keep it as is :)

compiler/rustc_mir_build/src/thir/constant.rs

compiler/rustc_trait_selection/src/traits/wf.rs

compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

compiler/rustc_mir_build/src/thir/pattern/mod.rs

compiler/rustc_mir_build/src/thir/constant.rs

BoxyUwU · 2026-02-08T17:41:24Z

cool! sorry for a lot of comments but this is looking really good :)

reddevilmidzy · 2026-02-09T16:13:51Z

In my current code, an ICE will occur in the tests/ui/const-generics/generic_const_exprs/lit_type_mismatch.rs test.

Looking at the stacktrace and log, it appears that after returning None due to a type mismatch, the path continues without stopping at hir_ty_lowering, which then instantiates the default value. This causes an ICE error as instantiate is called with an empty preceding_args.

How would you recommend handling this situation?

reddevilmidzy · 2026-02-09T16:16:34Z

cool! sorry for a lot of comments but this is looking really good :)

No worries at all — I really appreciate the detailed feedback. Thanks for taking the time to review (_ _)

rust-log-analyzer · 2026-02-09T16:24:50Z