-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Encountered error Unimplemented
selecting <...> during codegen
#58375
Comments
Unable to reproduce, can't install tarpaulin:
|
If you are able to run it, can you run the command verbosely to extract the entire rustc command line? If you then run that command line yourself, does that also ICE? |
@jethrogb Here is what I have. Note that I ran
Meta
|
@ckaran I was hoping running tarpaulin verbosely would provide some more info, but unfortunately it doesn't really... Can you provide instructions on how to reproduce (including tarpaulin install) on a clean system, or docker container, or something like that? |
@jethrogb Did you get my last comment? I did as you asked yesterday, adding it as a comment, along with a ridiculously long copied chunk of standard out from re-running tarpaulin (it turns out you need to set |
@ckaran no I got nothing. Sounds like GitHub ate your comment unfortunately. |
@jethrogb OK, I don't have time at the moment, but I'll work on putting something together in my repo that outlines shows what I'm seeing. |
@jethrogb I've updated the repository at https://github.com/ckaran/rustc_issue_report_58375 with the output from If that still doesn't work for you, everything I've done is within a virtual machine; as soon as I can figure out how to get a ~13 GB file to you, I could send it to you so you could play around with it and see what I'm seeing. |
Can you run it again but with
|
@jethrogb Done. Pull the latest commit from the repository. Thank you for looking into this! |
Reproduced by doing
in crate proptest version 0.9.1 |
Significantly reduced reproduction in ckaran/rustc_issue_report_58375#1 . I would like it to be smaller still, though. |
Also was able to reproduce on Rust 1.24.0, so it's at least not a recent regression. https://github.com/jethrogb/rustc_issue_report_58375/tree/1.24.0 . Since this blows up on |
@jethrogb I left a comment on your PR to my repository, but I'm going to leave the same comment here, so that others can read the thread and know what we talked about (mea culpa for not commenting here originally!) Based on what you've said above, it appears that what you pushed fully reproduces the problem for you, correct? If so, I'll merge the PR. Do you want me to leave the repository up until the regression is fixed, or is there a better place to put the code? Were you able to install tarpaulin and see the same results as well? |
This is a regression from 1.23.0 to 1.24.0 Fully reduced: pub struct DecodeUtf16<I: Iterator<Item = u16>>(I);
pub trait Arbitrary {
type Strategy;
fn arbitrary_with() -> Self::Strategy;
fn arbitrary() {}
}
impl Arbitrary for DecodeUtf16<<Vec<u16> as IntoIterator>::IntoIter> {
type Strategy = Self;
fn arbitrary_with() -> Self::Strategy {
unimplemented!()
}
} Compile with Now that we have a reduced test case can someone from the compiler team look at this? @nikomatsakis |
@jonas-schievink can you update the issue labels as appropriate? |
injected between nightly-2018-01-04 and nightly-2018-01-05 |
Here are the PR's from that time frame:
I think #46916 looks quite relevant. |
(Although I don't think #46916 necessarily injected the bug; it may have just exposed a pre-existing bug.) |
triage: marking P-high. |
assigning to @aturon for initial investigation. |
removing nomination now that this is assigned. |
@aturon Have you figured out anything about this bug? |
Any news? Since the assignment more than a month ago, there seems to have been zero updates or progress. For a stable-to-stable regression, I would have expected more priority. @nikomatsakis (as compiler team lead), should this be reassigned? |
Unassigning from @aturon, with intent to assign to someone else at today's rustc meeting. |
I've been looking at the reduced test case and trying to see if I can determine the root cause. It would make sense if #46916 has caused this regression; it looks like the compiler is selecting an impl for some piece of code but not finding a matching impl. It seems likely this is because the impl itself was removed for being unused, except clearly some code referencing it is clearly still alive -- I'm guessing #46916 revived the latter part but not the former part. I've been trying to figure out which part of the code might be cleaning out unused trait impls, but this is my first time hacking the compiler so that will likely take me some time. |
Proptest seems to be hitting this rust-lang/rust#58375
I ran into this a couple of days ago trying to enable code coverage for https://github.com/alessandrod/nuts so I decided to take a stab at it. This is the first time I look at the compiler so apologies if what follows is inaccurate and a waste of your time. 🙏 I took @jethrogb's test case and reduced it a bit further: (I've also made a test case for it: https://github.com/alessandrod/rust/blob/12e230759447b37ed7a0fc18f971caaa10b869e6/src/test/run-pass/issue-58375-monomorphize-default-impls.rs) pub struct DecodeUtf16<I>(I);
pub trait Arbitrary {
fn arbitrary() {}
}
pub trait A {
type Item;
}
impl A for u8 {
type Item = char;
}
impl Arbitrary for DecodeUtf16<<u8 as A>::Item> {
} Poking around I noticed that when the last impl is "instantiated" (sorry I know the terminology is inaccurate), Then the eager monomorphizing collector (tm) code enabled by rust/src/librustc_mir/monomorphize/collector.rs Lines 1158 to 1171 in db592f4
Those Normalizing does seem to fix the bug: alessandrod@12e2307 I haven't created a pull request because this is all still well beyond my pay grade. I've ran the tests locally tho and to my surprise everything seems to pass. Hope this helps! |
@alessandrod great work! The best way to get this reviewed is probably to post this as a PR anyway -- just mention in the description that this is your first and reviewers will no doubt treat you gently. |
nominating for discussion at compiler meeting if @alessandrod or someone else puts up a PR with the proposed fix before the next compiler meeting, great! But if no PR goes up, then the team should at least discuss the solution put forth there. (And, maybe, whether the existing APi's could be revised to make these kinds of bugs harder to run into? Just a stray thought on my part...) |
Normalize type parameters in create_mono_items_for_default_impls. Fix for #58375. I've added a test in `src/tests/run-pass` to reproduce the bug, not sure that's the best place for it. See #58375 (comment) for more context.
Looks like this has been fixed. Thanks, @alessandrod! |
If fixed, should this issue now be closed? |
Closing, thanks! |
Thank you @alessandrod for fixing this! I finally had the chance to test this on latest nightly, and it works! Now I just have to fix the (large) number of holes in my test cases... |
Update by pnkfelix: reduction to isolated test showing regression from 1.23.0 to 1.24.0 is given in comment below.
Original bug report follows
I'm using cargo-tarpaulin to ensure that my tests using proptest are covering all cases. In the process of testing this out, I ran into the following error:
EDIT A fairly small repository illustrating the bug can be found here.
Meta
rustc --version --verbose
:Backtrace
The only information that I got from the command is given above. If you know of better commands I can try to use, I can do so and amend this report.
The text was updated successfully, but these errors were encountered: