Do not resolve associated const when there is no provided value

[compiler-errors]

Fixes #98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.

---

The root issue here is that when we're looking for the defining LeafDef in resolve_associated_item, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.

This root issue becomes problematic (as in #98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.

I'm not exactly sure why this bug arises due to #96591 -- perhaps valtrees are evaluated more eagerly than in the old system?

r? @oli-obk or @lcnr since y'all are familiar with const eval and reviewed #96591, though feel free to reassign.

This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?

[rustbot]

Some changes occurred in const_evaluatable.rs

cc @lcnr

[compiler-errors]

TooGeneric here is a bit of a misnomer, since it really should be "not concrete" or something.

[lcnr]

🤔 it's weird that we have to actually deal with TooGeneric here 🤔

this should already be guarded against by the uniify_failure_kind. Do any tests change if you always use

let guar = infcx.tcx.sess.delay_span_bug(
                    span,
                    format!("Missing value for constant, but no error reported?"),
                );
                NotConstEvaluatable::Error(guar)

[compiler-errors]

I changed this to always delay a bug, and not specially deal with TooGeneric in the case of infer/param types:

        match concrete {
            Err(ErrorHandled::TooGeneric) => Err({
                let guar = infcx.tcx.sess.delay_span_bug(
                    span,
                    format!("Missing value for constant, but no error reported?"),
                );
                NotConstEvaluatable::Error(guar)
            }),

and I get two ICEs, see this gist: https://gist.github.com/compiler-errors/146cd973d15ddc7fcfee6ff28a9ac5e0

Was that what you were asking me to try, @lcnr?

[lcnr]

yeah, so InferCtxt::const_eval_resolve is not not doing what we need for this

rust/compiler/rustc_infer/src/infer/mod.rs

Lines 1664 to 1671 in 03d488b

	if substs.has_infer_types_or_consts() {
	let ac = AbstractConst::new(self.tcx, unevaluated.shrink());
	if let Ok(None) = ac {
	substs = InternalSubsts::identity_for_item(self.tcx, unevaluated.def.did);
	} else {
	return Err(ErrorHandled::TooGeneric);
	}
	}

I guess what we should do is:
match on AbstractConst::new(self.tcx, unevaluated.shrink());

Ok(None) is already correct.
Err(emitted) -> NotConstEvaluatable::Error(emitted)
Ok(Some(x)) -> the inference vars aren't used in the anon const, replace them with placeholders

feel free to do that in this PR, otherwise r=me

[compiler-errors]

@lcnr: I'm gonna do it in a follow-up PR, since this solution doesn't really rely on that change, does it?

[lcnr]

r=me after dealing with the first comment

[lcnr]

r? @lcnr

[compiler-errors]

@bors r=lcnr

[bors]

📌 Commit c8165c5 has been approved by lcnr

It is now in the queue for this repository.

[pnkfelix]

Discussed in T-compiler meeting. Declining to backport, though if someone wants to make a strong argument for it, you can renominate.

(The heart of the discussion is that I was/am nervous about the change, while @oli-obk 's opinion is that "the fix is fairly simple and the problem is annoying to debug when hit". I'm mainly curious to know how @lcnr feels, since they had suggestions on follow-up changes that should be made to this code as well.)

@rustbot label: -beta-nominated

[Dylan-DPC]

failed in rollup ci

@bors r-

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[compiler-errors]

@bors r=lcnr

[bors]

📌 Commit 22b2aae has been approved by lcnr

It is now in the queue for this repository.