rust 1.25.0 internal compiler error #49482
Comments
matthewjasper
added
I-ICE
|
I've experienced a similar problem when running I also tried it out locally with the same result. But I noticed that |
|
In my case, this behavior depends on target (windows, osx, linux x86_64 without cross-compilation works fine), but other targets (arm, mips, i565) are unstable, depending on debug/release profile and target architecture. Also, I observed two types of error messages: 'index out of bounds: the len is 10 but the index is 14' and 'index out of bounds: the len is 10 but the index is 10'. |
|
I've also been having trouble trying to compile it in Crux: I can't compile successfully 1.24.1 or 1.25.0. |
|
According to the discussion in IRC, this is probably related to #47181 |
|
The bisection results are:
Regression was introduces in one of these commits: 51b0b37...e6072a7 |
|
I have not been able to reproduce this yet. rust-lightning-invoice does not build for me. @glebpom, do you have a small sample project that exposes the problem? Also, could you try if this issue also occurs with a recent nightly version of the compiler? |
|
@michaelwoerister I guess you took the version that did compile with 1.24.1 on travis? What error do you get when you try to compile rust-lightning-invoice? |
|
@michaelwoerister I was able to extact a very small code, which make rustc panicking. Please, take a look on this repo https://github.com/glebpom/rustc-panic |
|
@glebpom Thanks a lot! I'll take a look as soon as I get a chance. |
|
Hey, @michaelwoerister any updates here? Can I help somehow with the debugging? |
|
Yes, I can reproduce with the latest nightly on Linux. Thanks for the test case! |
|
@michaelwoerister Can this still be reproduced? |
XAMPPRocky
added
T-compiler
|
@Aaronepower it still panics on latest nightly using #49482 (comment) |
|
Nominating for priority assignment. |
|
triage: P-high |
|
assigning to @michaelwoerister as they were most recent compiler expert to locally reproduce, and its theorized that it may be related to PR #47181 |
|
visiting for triage. No progress yet. Should consider either reassigning or lowering priority if we are still stalled next week. |
|
So, this still reproduces, but it is a bit of a head-scratcher for me. The compiler ICE when trying to lookup a rust/src/librustc_metadata/cstore_impl.rs Line 401 in 78ec12d In the past, most cases where this happened were related to proc-macro crates which, in general, have weird/inconsistent crate metadata. However, trying to filter out proc-macro crates during visible-parent-map generation does not seem to help. Don't know yet what's going on here. I guess the most valid solution would be to fix crate metadata for proc-macro crates. I don't think I'll have time to look into that soon, though. |
|
Visiting for compiler meeting. @michaelwoerister has done investigation (as you can see) but we still don't really know what's going on here. :( |
|
Successfully reproduced this. |
|
Minified: in lib.rs: #[macro_use]
extern crate binary_macros;
pub trait KvStorage
{
fn get(&self);
}
impl<K> KvStorage for Box<K>
where
K: KvStorage + ?Sized,
{
fn get(&self) {
(**self).get()
}
}in #[allow(unused_imports)]
#[macro_use]
extern crate binary_macros_impl;
pub use binary_macros_impl::*;in extern crate proc_macro;
macro_rules! proc_macro_tokenstream {
() => {
::proc_macro::TokenStream
};
}
macro_rules! proc_macro_expr_impl {
($(
$( #[$attr:meta] )*
pub fn $func:ident($input:ident: &str) -> String $body:block
)+) => {
$(
// Parses an input that looks like:
//
// ```
// #[allow(unused)]
// enum ProcMacroHack {
// Input = (stringify!(ARGS), 0).1,
// }
// ```
$( #[$attr] )*
#[proc_macro_derive($func)]
pub fn $func(input: proc_macro_tokenstream!()) -> proc_macro_tokenstream!() {
panic!()
}
)+
};
}
proc_macro_expr_impl! {
pub fn base2_impl(input: &str) -> String {
panic!()
}
pub fn base4_impl(input: &str) -> String {
panic!()
}
pub fn base8_impl(input: &str) -> String {
panic!()
}
pub fn base16_impl(input: &str) -> String {
panic!()
}
pub fn base32hex_impl(input: &str) -> String {
panic!()
}
pub fn base32_impl(input: &str) -> String {
panic!()
}
pub fn base64_impl(input: &str) -> String {
panic!()
}
pub fn base64url_impl(input: &str) -> String {
panic!()
}
pub fn base2_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base4_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base8_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base16_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base32hex_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base32_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base64_nopad_impl(input: &str) -> String {
panic!()
}
pub fn base64url_nopad_impl(input: &str) -> String {
panic!()
}
}steps: |
|
The problem is that the "imaginary" I'll try to do that tomorrow. |
At least the incremental compilation code, and a few other places in the compiler, require the CrateMetadata for a loaded target crate to contain a valid DefIdTable for the DefIds in the target. Previously, the CrateMetadata for a proc macro contained the crate's "host" DefIdTable, which is of course incompatible with the "target" DefIdTable, causing ICEs. This creates a DefIdTable that properly refers to the "proc macro" DefIds. Fixes rust-lang#49482.
create a valid DefIdTable for proc macro crates At least the incremental compilation code, and a few other places in the compiler, require the CrateMetadata for a loaded target crate to contain a valid DefIdTable for the DefIds in the target. Previously, the CrateMetadata for a proc macro contained the crate's "host" DefIdTable, which is of course incompatible with the "target" DefIdTable, causing ICEs. This creates a DefIdTable that properly refers to the "proc macro" DefIds. Fixes #49482. r? @michaelwoerister Should we beta-nominate this?
|
So -- there is a fix for this issue in #53711. One thing we are trying to decide is whether to backport this fix to the current beta (in which case it would appear in stable in 1.29) or to let it ride the trains (in which case the fix would appear in 1.30). We would normally backport, but the fix is mildly non-trivial and so there is perhaps some risk for follow-on bugs. I'm curious @glebpom and others to get your take on whether to backport or not. |
|
(It would perhaps be best if you commented in #53711 directly though) |
I upgrade the rust to 1.25 and compilation starts failing. I use linux musl target
I tried this code:
cargo checkI expected to see this happen: Compile successful as it is on 1.24.1
Instead, this happened:
Meta
rustc --version --verbose:Backtrace:
The text was updated successfully, but these errors were encountered: