RLS ICE: "node_type: no type for node" when building bitflags #59134
Assignees
Labels
A-rls
Area: Rust Language Server (RLS)
A-save-analysis
Area: saving results of analyses such as inference and borrowck results to a file.
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-high
High priority
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-dev-tools
Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Comments
jonas-schievink
added
I-ICE
That's weird, I don't think RLS runs |
|
i had enabled dev overrides for dependencies in cargo.toml using: removing that out the output from rls is now the normal debug flags but still the same errors: |
jonas-schievink
added
A-save-analysis
|
This is now causing widespread ICEs in the RLS. Nominating to get this fixed (maybe @Xanewok has an idea?). See #60484 (comment) for a simpler reproducer. |
jonas-schievink
added
the
T-dev-tools
|
I encountered this issue trying out winit which causes rustc to crash on this line when invoked by RLS. I can confirm it's the exact same backtrace as #60484 (comment). |
This was referenced May 4, 2019
Compiler panics on latest RLS when compiling crates that depend on
bitflags 1.0.5
rust-lang/rls#1449
Closed
jonas-schievink
changed the title
|
I ran into this trying out https://github.com/fdehau/tui-rs on Windows 10. RLS inside vscode ends up panicking with this backtrace: (note for repro: I had changed the default feature in tui-rs Cargo.toml to be "crossterm" because the default feature "termion" doesn't compile on windows - but after the termion compile errors, rustc was giving me a similar panic anyway) |
|
JFYI I could work around this problem by adding |
This comment has been minimized.
This comment has been minimized.
|
Thanks @hcrohland ! |
|
Running into the same issue when trying to build Clap |
|
Same issue in vscode on linuxmint and rust 1.34.1 when trying to build glib (dependency of gtk). |
|
There is no need to list every crate which depends on |
|
Here's a small repro, extracted from what struct BF { bits: u32 }
impl BF {
pub const F: BF = BF { bits: 0 };
pub const fn f() {
trait _BF {
const FLAG: u32 = 0;
}
impl _BF for BF {
const FLAG: u32 = F.bits;
}
}
}I'm struggling to get a repro without the compile error, though. |
|
Thank you for such a small repro! I’ll take a closer look tomorrow and see
what may be causing that.
…On Tue, 7 May 2019 at 22:32, Sean Gillespie ***@***.***> wrote:
Here's a small repro, extracted from what bitflags is doing:
struct BF { bits: u32 }
impl BF {
pub const F: BF = BF { bits: 0 };
pub const fn f() {
trait _BF {
const FLAG: u32 = 0;
}
impl _BF for BF {
const FLAG: u32 = F.bits;
}
}
}
▶ RUST_BACKTRACE=1 cargo +nightly rustc --lib -- -Zsave-analysis
Compiling rlsrepro v0.1.0 (/Users/swgillespie/Documents/workspace/rust/repros/rlsrepro)
error[E0425]: cannot find value `F` in this scope
--> src/lib.rs:11:31
|
11 | const FLAG: u32 = F.bits;
| ^ not found in this scope
error: internal compiler error: src/librustc/ty/context.rs:565: node_type: no type for node `expr F (hir_id=HirId { owner: DefIndex(0:10), local_id: 2 })`
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:643:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::_print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
6: std::panicking::begin_panic
7: rustc_errors::Handler::bug
8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
9: rustc::ty::context::tls::with_opt::{{closure}}
10: rustc::ty::context::tls::with_context_opt
11: rustc::ty::context::tls::with_opt
12: rustc::util::bug::opt_span_bug_fmt
13: rustc::util::bug::bug_fmt
14: rustc::ty::context::TypeckTables::node_type::{{closure}}
15: rustc::ty::context::TypeckTables::expr_ty_adjusted
16: rustc_save_analysis::SaveContext::get_expr_data
17: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_expr
18: rustc_save_analysis::dump_visitor::DumpVisitor<O>::process_assoc_const
19: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_item
20: rustc_save_analysis::dump_visitor::DumpVisitor<O>::process_method
21: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_item
22: <rustc_save_analysis::dump_visitor::DumpVisitor<O> as syntax::visit::Visitor>::visit_mod
23: <rustc_save_analysis::DumpHandler as rustc_save_analysis::SaveHandler>::save
24: rustc::dep_graph::graph::DepGraph::with_ignore
25: rustc_driver::run_compiler::{{closure}}::{{closure}}::{{closure}}
26: rustc::util::common::time
27: rustc::ty::context::tls::enter_global
28: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
29: rustc_interface::passes::create_global_ctxt::{{closure}}
30: rustc_interface::passes::BoxedGlobalCtxt::enter
31: rustc_interface::interface::run_compiler_in_existing_thread_pool
32: std::thread::local::LocalKey<T>::with
33: scoped_tls::ScopedKey<T>::set
34: syntax::with_globals
query stack during panic:
end of query stack
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0425`.
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.36.0-nightly (a19cf18 2019-05-06) running on x86_64-apple-darwin
note: compiler flags: -Z save-analysis -C debuginfo=2 -C incremental --crate-type lib
note: some of the compiler flags provided by cargo are hidden
error: Could not compile `rlsrepro`.
To learn more, run the command again with --verbose.
I'm struggling to get a repro without the compile error, though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#59134 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAXTFXP5WJIJ5CT7FJWYBNTPUHRNNANCNFSM4G5NMYJA>
.
|
|
Looks like |
Correct, it does. Further minimized repro: fn bar() {
struct Foo;
trait FooT {
const FLAG: u32;
}
impl FooT for Foo {
const FLAG: u32 = bogus.baz;
}
} |
|
Interesting. I managed to reduce it to: fn func() {
trait Trait {
const CONST: u32 = bogus.field;
}
}with: Any other combination is okay, it has to be I'm only guessing but it seems that it tries to emplace |
|
I think this is confirmed by rust/src/librustc/ty/context.rs Lines 246 to 266 in c3694e5 A, what I believe is, more accurate guess is that we somehow don't correctly nest appropriate typeck tables when visiting |
|
Oh, you need to have one table per body: look in HIR for This makes a lot more sense now: so |
|
What about this: --- a/src/librustc_save_analysis/dump_visitor.rs
+++ b/src/librustc_save_analysis/dump_visitor.rs
@@ -465,7 +465,7 @@ impl<'l, 'tcx: 'l, 'll, O: DumpOutput + 'll> DumpVisitor<'l, 'tcx, 'll, O> {
// walk type and init value
self.visit_ty(typ);
if let Some(expr) = expr {
- self.visit_expr(expr);
+ self.nest_tables(id, |v| v.visit_expr(expr));
}Seems like we need to |
|
Hm, probably! I imagined the problem is we don't nest it before visiting trait items (hence missing |
|
With the fix applied this still ICEs on (this time for type) fn func() {
trait Trait {
type MyType;
const CONST: Self::MyType = bogus.field;
}
}which means we should nest tables for |
bors
added a commit
that referenced
this issue
May 13, 2019
save-analysis: Fix ICE when processing associated constant Closes #59134 Closes rust-lang/rls#1449 Thanks @swgillespie for helping tracking this down and fixing it! r? @eddyb
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using this branch of bitflags: bitflags/bitflags#172 through a patch in a local directory rls crashes with the following errors:
The text was updated successfully, but these errors were encountered: