Add TooGeneric variant to LayoutError and emit Unknown

[FedericoBruzzone]

What's in this PR?

• Add TooGeneric variant to LayoutError and emit Unknown one
• Return ErrorGuaranteed from items_of_instance query

With this PR these issues and their respective ICEs are resolved:

• fixes ICE: encountered unexpected unsized field in layout of #135020
• fixes ICE: "Missing value for constant, but no error reported?" with uncomputable layout due to trivial bounds #135138
• fixes ICE -Zpolymorphize=on "collection encountered polymorphic constant: Unevaluated(UnevaluatedConst" #105249
• fixes ICE while compiling crossbeam-epoch 0.9.15 with -Zpolymorphize=on" #118913

For instance, given this code:

#![feature(trivial_bounds)]

fn return_str()
where
    str: Sized,
{
    [(); { let _a: Option<str> = None; 0 }];
}

the following error is generated

error[E0080]: evaluation of constant value failed
 --> ice-135138.rs:7:16
  |
7 |     [(); { let _a: Option<str> = None; 0 }];
  |                ^^ cannot determine the layout of the type `Option<str>`

Then, according to @lukas-code: "Keeping this assertion in some sensible manner seems like it would be more effort than it's worth". So, I decided to remove it and the ICE related to #135138 has been fixed.

rust/compiler/rustc_ty_utils/src/layout.rs

Lines 107 to 111 in 6ca6659

	if !field.ty.is_sized(cx.tcx(), cx.typing_env) {
	cx.tcx().dcx().delayed_bug(format!(
	"encountered unexpected unsized field in layout of {ty:?}: {field:#?}"
	));
	}

[rustbot]

r? @cjgillot

rustbot has assigned @cjgillot.
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

[rustbot]

HIR ty lowering was modified

cc @fmease

[FedericoBruzzone]

Feel free to ask me anything.
In particular, let me know if you would like the addition of a test within the tests/ui/layout/ folder.

[jieyouxu]

(The fluent slug needs to be sorted lexicographically)

[jieyouxu]

error[E0080]: evaluation of constant value failed
 --> ice-135138.rs:7:16
  |
7 |     [(); { let _a: Option<str> = None; 0 }];
  |                ^^ cannot determine the layout of the type `Option<str>`

seems somewhat unfortunate diagnostics-wise because:

• The error is quite generic and isn't super helpful to the user (e.g. why can't the compiler determine the layout?), because it doesn't actually point to the "root" problem, which is Option<str>.
• The problem here is that Option<str> doesn't have a size known at, er, const-eval time?

Introducing this UnexpectedUnsized variant to LayoutError and removing the assertion seems a bit strange to me, won't this paper over genuine implementation bugs, even if this variant is only constructed under trivial_bounds? I do appreciate that the layout calculation is not trivial, so, not a blocker.

Anyway, cc @lukas-code.

[lukas-code]

In particular, let me know if you would like the addition of a test within the tests/ui/layout/ folder.

Yes, this definitely needs tests, for both of the issues. See here for a guide on adding tests.

[rustbot]

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

[FedericoBruzzone]

If it isn't immediately required for this PR, I'd prefer to remove it or move it to another PR for now.

We should be there, let me know @lukas-code :D

[lukas-code]

I had missed this case before, but there can actually be unevaluated constants that are rigid but not generic. In this case the LayoutError::TooGeneric here is still wrong:

#![feature(trivial_bounds)]

trait Project {
    const ASSOC: usize;
}

fn foo()
where
    (): Project,
{
    [(); <() as Project>::ASSOC];
}

We already normalize above in fn layout_of so checking for aliases and normalizing here looks redundant anyway -- can we just remove it?

[FedericoBruzzone]

Yes, we can just remove it.

This is currently an ICE:

error: internal compiler error: Missing value for constant, but no error reported?
  --> tests/ui/layout/uneval-const-rigid.rs:11:5
   |
11 |     [(); <() as Project>::ASSOC];
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: delayed at compiler/rustc_trait_selection/src/traits/const_evaluatable.rs:132:44 - disabled backtrace
  --> tests/ui/layout/uneval-const-rigid.rs:11:5
   |
11 |     [(); <() as Project>::ASSOC];
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Can we fix it in another PR? I will open an issue if yes. @lukas-code

[lukas-code]

Ah yes, I see now that this is actually a different issue. So yes, feel free to open a new issue and you don't have to fix it here.

But then I'm also wondering whether the case where count is unevaluated but doesn't have params is actually reachable, because now I can't come up with an example for that.

[FedericoBruzzone]

I will investigate as soon as possible. That case may be unreachable, but I am not sure. @lukas-code

[bors]

☔ The latest upstream changes (presumably #135519) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

@bors delegate=lukas-code

[bors]

✌️ @lukas-code, you can now approve this pull request!

If @oli-obk told you to "r=me" after making some further change, please make that change, then do @bors r=@oli-obk