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

Panic rustc 1.31.0-nightly (96064eb61 2018-10-28) running on x86_64-pc-windows-msvc: in hir_id_validator.rs:31 #55475

Closed
kjeremy opened this issue Oct 29, 2018 · 9 comments · Fixed by #56143
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.

Comments

@kjeremy
Copy link

kjeremy commented Oct 29, 2018

Trying to build: https:/rust-analyzer/rust-analyzer latest nightly rustc 1.31.0-nightly (96064eb 2018-10-28) running on x86_64-pc-windows-msvc panics.

RUST_BACKTRACE=1 cargo +nightly check
Checking idna v0.1.5
Checking ra_syntax v0.1.0 (C:\projects\test\rust-analyzer\crates\ra_syntax)
thread 'main' panicked at 'librustc\hir\map\hir_id_validator.rs:31:
ItemLocalIds not assigned densely in ::grammar[0]::expressions[0]::{{?}}[1]. Max ItemLocalId = 4, missing IDs = ["[local_id: 1, node:unknown node (id=13965)]", "[local_id: 2, node:path segment super (id=13964)]"]; seens IDs = ["(NodeId(13963) use grammar::expressions::{{?}} (id=13963))", "(NodeId(13967) path segment atom (id=13967))", "(NodeId(13966) path segment self (id=13966))"]
HirIdValidator: The recorded owner of path segment super (id=13964) is ::grammar[0]::expressions[0]::{{?}}[1] instead of ::grammar[0]::expressions[0]::{{?}}[2]
HirIdValidator: Same HirId ::grammar[0]::expressions[0]::{{?}}[2]/2 assigned for nodes path segment super (id=13964) and path segment atom (id=60792)
HirIdValidator: The recorded owner of path segment super (id=13964) is ::grammar[0]::expressions[0]::{{?}}[1] instead of ::grammar[0]::expressions[0]::{{?}}[3]
HirIdValidator: Same HirId ::grammar[0]::expressions[0]::{{?}}[3]/2 assigned for nodes path segment super (id=13964) and path segment atom (id=60795)', librustc\util\bug.rs:47:26
stack backtrace:
0: <std::future::SetOnDrop as core::ops::drop::Drop>::drop
1: std::panicking::take_hook
2: std::panicking::take_hook
3: <rustc::ty::sty::Binder<rustc::ty::ProjectionPredicate<'tcx>> as rustc::ty::ToPredicate<'tcx>>::to_predicate
4: std::panicking::rust_panic_with_hook
5: rustc::ty::query::on_disk_cache::__ty_decoder_impl::<impl serialize::serialize::Decoder for rustc::ty::query::on_disk_cache::CacheDecoder<'a, 'tcx, 'x>>::read_u32
6: rustc::ty::context::tls::track_diagnostic
7: rustc::ty::context::tls::track_diagnostic
8: rustc::ty::context::tls::track_diagnostic
9: rustc::ty::context::tls::track_diagnostic
10: rustc::util::bug::bug_fmt
11: rustc::util::bug::bug_fmt
12: <rustc::hir::def_id::LocalDefId as core::fmt::Debug>::fmt
13: rustc::hir::map::map_crate
14: rustc_driver::driver::build_output_filenames
15: rustc_driver::driver::compile_input
16: rustc_driver::run_compiler
17: <rustc_driver::profile::trace::Query as core::fmt::Debug>::fmt
18: rustc_driver::run_compiler
19: <rustc_driver::profile::trace::Query as core::fmt::Debug>::fmt
20: <rustc_driver::pretty::IdentifiedAnnotation<'hir> as rustc_driver::pretty::PrinterSupport>::sess
21: _rust_maybe_catch_panic
22: rustc_driver::target_features::add_configuration
23: rustc_driver::main
24:
25: std::panicking::update_panic_count
26: _rust_maybe_catch_panic
27: std::rt::lang_start_internal
28:
29:
30: BaseThreadInitThunk
31: RtlUserThreadStart
query stack during panic:
end of query stack

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https:/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.31.0-nightly (96064eb 2018-10-28) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile ra_syntax.
warning: build failed, waiting for other jobs to finish...
error: build failed

@phansch
Copy link
Member

phansch commented Oct 29, 2018

Looks similar to the ICE in #55376, but the error is slightly different.

cc @nrc

@shepmaster
Copy link
Member

not just on Windows — affecting the playground as well:


   Compiling jpeg-decoder v0.1.15
   Compiling tokio-tcp v0.1.2
   Compiling tokio-uds v0.2.3
   Compiling tokio-udp v0.1.2
   Compiling crossbeam v0.4.1
   Compiling syntex_pos v0.59.1
   Compiling serde_urlencoded v0.5.3
   Compiling serde_json v1.0.32
   Compiling uuid v0.7.1
   Compiling toml v0.4.8
   Compiling csv v1.0.2
   Compiling image v0.20.0
   Compiling tokio v0.1.11
   Compiling syntex_errors v0.59.1
   Compiling hyper v0.12.13
thread 'main' panicked at 'librustc/hir/map/hir_id_validator.rs:31: 
HirIdValidator: The recorded owner of path segment super (id=36924) is ::server[0]::conn[0]::{{?}}[34] instead of ::server[0]::conn[0]::{{?}}[34]::{{?}}[0]
HirIdValidator: Same HirId ::server[0]::conn[0]::{{?}}[34]::{{?}}[0]/2 assigned for nodes path segment super (id=36924) and path segment spawn_all (id=89958)', librustc/util/bug.rs:47:26
note: Run with `RUST_BACKTRACE=1` for a backtrace.

@nrc
Copy link
Member

nrc commented Oct 30, 2018

Do you have a code sample which triggers this? It might be fixed by #55487

@kjeremy
Copy link
Author

kjeremy commented Oct 30, 2018 via email

@kjeremy
Copy link
Author

kjeremy commented Nov 1, 2018

@nrc #55487 did not fix the issue. I will try to come up with some sample code.

@shepmaster
Copy link
Member

It did fix my case — the playground is compiling again.

@ordian
Copy link

ordian commented Nov 6, 2018

Still reproducible with nightly-x86_64-unknown-linux-gnu 13dab66 2018-11-05.

@oli-obk
Copy link
Contributor

oli-obk commented Nov 21, 2018

This seems to have hit beta prematurely via a backport (see #56128)

@oli-obk oli-obk added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ labels Nov 21, 2018
@nikomatsakis
Copy link
Contributor

Pending fix in #56143

@nagisa nagisa added the P-high High priority label Nov 22, 2018
bors added a commit that referenced this issue Nov 22, 2018
…y, r=petrochenkov

Issue 56128 segment id ice nightly

Tentative fix for #56128

From what I can tell, the problem is that if you have `pub(super) use foo::{a, b}`, then when we explode the `a` and `b`, the segment ids from the `super` path were not getting cloned. However, once I fixed *that*, then I ran into a problem that the "visibility" node-ids were not present in the final HIR -- this is because the visibility of the "stem" that is returned in this case was getting reset to inherited. I don't *think* it is a problem to undo that, so that the visibility is returned unmodified.

Fixes #55475
Fixes #56128

cc @nrc @petrochenkov
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants