-
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
RLS ICE: "node_type: no type for node" when building bitflags #59134
Comments
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:
|
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. |
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). |
bitflags
1.0.5
rust-lang/rls#1449
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 |
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
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: