Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handle ConstKind::Unresolved after monomorphizing #70249

Merged
merged 3 commits into from
Mar 23, 2020

Conversation

lcnr
Copy link
Contributor

@lcnr lcnr commented Mar 21, 2020

fixes #70125

r? @bjorn3

@Centril Centril added the F-const_generics `#![feature(const_generics)]` label Mar 21, 2020
@Centril
Copy link
Contributor

Centril commented Mar 21, 2020

cc @eddyb @varkor

Comment on lines 43 to 44
// repeatedly monomorphize generic parameters until we either
// reach a value or an error.
Copy link
Member

Choose a reason for hiding this comment

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

This is in the wrong direction. You should never monomorphize more than once.
If the result isn't monomorphic, something went very wrong.

Copy link
Member

@eddyb eddyb Mar 22, 2020

Choose a reason for hiding this comment

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

@davidtwco and I recently spent some time tracking down cases of multiple monomorphization, as they broke down their "polymorphization" work (right now nothing happens if you apply the same substitutions more than once in codegen, because the substitutions themselves are monomorphic, but that doesn't make it correct, and it certainly breaks down with polymorphization).

}
ty::ConstKind::Value(value) => Ok(value),
_ => {
let const_ = self.monomorphize(&constant.literal);
Copy link
Member

Choose a reason for hiding this comment

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

What you could try is first always monomorphize-ing, and then checking for Unevaluated (you'd need to remove let substs = self.monomorphize(&substs);).

It's not the right fix here (see #70125 (comment)), but it could be useful for handling the erroring constant case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, this already seems to fix all tests 🤔 Will still look into your comment on #70125

@lcnr lcnr changed the title repeatedly monomorphize in eval_mir_constant handle ConstKind::Unresolved after monomorphizing Mar 22, 2020
Comment on lines +43 to +56
match self.monomorphize(&constant.literal).val {
ty::ConstKind::Unevaluated(def_id, substs, promoted) => self
.cx
.tcx()
.const_eval_resolve(ty::ParamEnv::reveal_all(), def_id, substs, promoted, None)
.map_err(|err| {
if promoted.is_none() {
self.cx
.tcx()
.sess
.span_err(constant.span, "erroneous constant encountered");
}
err
}),
Copy link
Member

Choose a reason for hiding this comment

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

@oli-obk @wesleywiser @varkor @yodaldevoid NB: this Unevaluated handling should, after #70125 (comment) is fixed, only handle the error case, whereas success should result in monomorphize itself doing the evaluation.

What do you think about merging this PR before that root cause is fixed?

Copy link
Member

@varkor varkor Mar 22, 2020

Choose a reason for hiding this comment

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

I'm happy to merge this interim fix if it addresses one of the existing ICEs 👍

@eddyb
Copy link
Member

eddyb commented Mar 22, 2020

@bors r+ as per #70249 (comment)

@bors
Copy link
Contributor

bors commented Mar 22, 2020

📌 Commit 8533778 has been approved by eddyb

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 22, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Mar 22, 2020
handle ConstKind::Unresolved after monomorphizing

fixes rust-lang#70125

r? @bjorn3
Centril added a commit to Centril/rust that referenced this pull request Mar 23, 2020
handle ConstKind::Unresolved after monomorphizing

fixes rust-lang#70125

r? @bjorn3
This was referenced Mar 23, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 23, 2020
Rollup of 9 pull requests

Successful merges:

 - rust-lang#69251 (#[track_caller] in traits)
 - rust-lang#69880 (miri engine: turn error sanity checks into assertions)
 - rust-lang#70207 (Use getentropy(2) on macos)
 - rust-lang#70227 (Only display definition when suggesting a typo)
 - rust-lang#70236 (resolve: Avoid "self-confirming" import resolutions in one more case)
 - rust-lang#70248 (parser: simplify & remove unused field)
 - rust-lang#70249 (handle ConstKind::Unresolved after monomorphizing)
 - rust-lang#70269 (remove redundant closures (clippy::redundant_closure))
 - rust-lang#70270 (Clean up E0449 explanation)

Failed merges:

r? @ghost
@bors bors merged commit 092c821 into rust-lang:master Mar 23, 2020
@lcnr lcnr deleted the issue70125 branch June 29, 2020 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-const_generics `#![feature(const_generics)]` S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[const_generics]: encountered bad ConstKind in codegen
5 participants