Skip to content

Erase regions if there are any region errors when collecting predicates#153105

Open
makai410 wants to merge 2 commits intorust-lang:mainfrom
makai410:erase-if-error
Open

Erase regions if there are any region errors when collecting predicates#153105
makai410 wants to merge 2 commits intorust-lang:mainfrom
makai410:erase-if-error

Conversation

@makai410
Copy link
Member

@makai410 makai410 commented Feb 25, 2026

Fixes: #152682

With the old trait solver, type_known_to_meet_bound_modulo_regions() isn't really operating "modulo regions" if there are any region errors, since normalize will just return a type error to the trait solver if given a ty with a region error, which then starts cascading when there are so many assumptions.

So I think it would be good to erase regions if there are any region errors before we normalize the type when collecting predicates for confirmation.

That said, I somehow feel like this is kind of ad-hoc... I'd really appreciate if someone more familiar with this code could take a closer look :3

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 25, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 25, 2026

r? @petrochenkov

rustbot has assigned @petrochenkov.
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
  • compiler expanded to 68 candidates
  • Random selection from 14 candidates

Comment on lines +13 to +40
error[E0277]: the size for values of type `[&usize]` cannot be known at compilation time
--> $DIR/ice-unsized-struct-const-eval-123154.rs:14:1
|
LL | static ST: AA = AA::new();
| ^^^^^^^^^^^^^ doesn't have a size known at compile-time
|
= help: within `AA`, the trait `Sized` is not implemented for `[&usize]`
note: required because it appears within the type `AA`
--> $DIR/ice-unsized-struct-const-eval-123154.rs:3:8
|
LL | struct AA {
| ^^
= note: statics and constants must have a statically known size

error[E0277]: the size for values of type `[&usize]` cannot be known at compilation time
--> $DIR/ice-unsized-struct-const-eval-123154.rs:9:23
|
LL | const fn new() -> Self { }
| ^^^^ doesn't have a size known at compile-time
|
= help: within `AA`, the trait `Sized` is not implemented for `[&usize]`
note: required because it appears within the type `AA`
--> $DIR/ice-unsized-struct-const-eval-123154.rs:3:8
|
LL | struct AA {
| ^^
= note: the return type of a function must have a statically known size

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway these errors will be triggered if the code don't have the lifetime error, so

@petrochenkov
Copy link
Contributor

r? types

@rustbot rustbot added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Feb 26, 2026
@rustbot rustbot assigned lcnr and unassigned petrochenkov Feb 26, 2026
Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so what's happening here is that type_is_sized_modulo_regions encounters a field of type ty::Error as normalizing <&'re_error [fn()] as core::ops::Deref>::Target results in a type error,

but then during const eval we normalize differently and don't get a type error as the output?

I feel like erasing error regions this way seems... unfortunate and maybe we should instead change the trait solver/type system to check for HAS_NON_REGION_ERROR when creating type errors 🤔

View changes since this review

@makai410
Copy link
Member Author

but then during const eval we normalize differently and don't get a type error as the output?

Yeah since they get the ty using normalize_erasing_regions which wont return a type error in this case.

@makai410
Copy link
Member Author

I feel like erasing error regions this way seems... unfortunate and maybe we should instead change the trait solver/type system to check for HAS_NON_REGION_ERROR when creating type errors 🤔

cool I'm going to try this to see if it would cause any regressions or something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ICE]: expected wide pointer extra data (e.g. slice length or trait object vtable) (missing lifetime)

4 participants