Skip to content

error: internal compiler error: src/librustc_typeck/check/mod.rs:2406: no type for node #57924

Closed

Description

@tbarrella

May be related to #47713

I tried this code: Compiling the project here, but at this line replacing Gcm with Self

I expected to see this happen: Code compiles or gives error messages

Instead, this happened: Compiler panicked with stack trace below

Meta

rustc --version --verbose:

rustc 1.32.0 (9fda7c223 2019-01-16)
binary: rustc
commit-hash: 9fda7c2237db910e41d6a712e9a2139b352e558b
commit-date: 2019-01-16
host: x86_64-apple-darwin
release: 1.32.0
LLVM version: 8.0

Backtrace:

> RUST_BACKTRACE=1 cargo build
   Compiling crypto-pure v0.0.9 (.../crypto-pure)
error: internal compiler error: src/librustc_typeck/check/mod.rs:2406: no type for node 30873: type E (id=30873) in fcx 0x7ffee86dd208

thread 'main' panicked at 'Box<Any>', src/librustc_errors/lib.rs:600:9
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_typeck::check::FnCtxt::node_ty
  15: <rustc_typeck::check::writeback::WritebackCx<'cx, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_ty
  16: rustc::hir::intravisit::walk_qpath
  17: <rustc_typeck::check::writeback::WritebackCx<'cx, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  18: rustc::hir::intravisit::walk_expr
  19: <rustc_typeck::check::writeback::WritebackCx<'cx, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  20: <rustc_typeck::check::writeback::WritebackCx<'cx, 'gcx, 'tcx> as rustc::hir::intravisit::Visitor<'gcx>>::visit_expr
  21: rustc_typeck::check::writeback::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::resolve_type_vars_in_body
  22: rustc::ty::context::tls::with_related_context
  23: rustc::infer::InferCtxtBuilder::enter
  24: rustc_typeck::check::typeck_tables_of
  25: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute
  26: rustc::ty::context::tls::with_context
  27: rustc::dep_graph::graph::DepGraph::with_task_impl
  28: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  30: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  31: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query
  32: rustc::session::Session::track_errors
  33: rustc_typeck::check::typeck_item_bodies
  34: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_item_bodies<'tcx>>::compute
  35: rustc::ty::context::tls::with_context
  36: rustc::dep_graph::graph::DepGraph::with_task_impl
  37: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  38: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  40: rustc::util::common::time
  41: rustc_typeck::check_crate
  42: rustc::ty::context::tls::enter_context
  43: <std::thread::local::LocalKey<T>>::with
  44: rustc::ty::context::TyCtxt::create_and_enter
  45: rustc_driver::driver::compile_input
  46: rustc_driver::run_compiler_with_pool
  47: <scoped_tls::ScopedKey<T>>::set
  48: rustc_driver::run_compiler
  49: rustc_driver::monitor::{{closure}}
  50: __rust_maybe_catch_panic
  51: rustc_driver::run
  52: rustc_driver::main
  53: std::rt::lang_start::{{closure}}
  54: std::panicking::try::do_call
  55: __rust_maybe_catch_panic
  56: std::rt::lang_start_internal
  57: main
query stack during panic:
#0 [typeck_tables_of] processing `<gcm::Gcm<E> as gcm::AeadCipher>::new`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack
error: aborting due to previous error


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.32.0 (9fda7c223 2019-01-16) running on x86_64-apple-darwin

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 `crypto-pure`.

To learn more, run the command again with --verbose.

Activity

  1. added
    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Jan 26, 2019
  2. memoryruins commented on Jan 27, 2019

    @memoryruins
    Contributor

    Panics on rustc 1.33.0-nightly (20c2cba61 2019-01-26) as well.

    Somewhat minimized:

    pub trait AeadCipher {
        fn new(key: &[u8]) -> Self;
    }
    
    pub trait BlockCipher {
        fn new(key: &[u8]) -> Self;
    }
    
    struct Processor<E> {
        block_cipher: E,
    }
    
    pub struct Gcm<E>(Processor<E>);
    
    impl<E: BlockCipher> AeadCipher for Gcm<E> {
        fn new(key: &[u8]) -> Self {
            // Gcm::<E>(Processor::<E>::new(key))
            Self::<E>(Processor::<E>::new(key)) // ICE
        }
    }
    
    impl<E: BlockCipher> Processor<E> {
        fn new(key: &[u8]) -> Self {
            Self {
                block_cipher: E::new(key),
            }
        }
    }

    https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=1f80547774e123df5705622a026e5104

  3. memoryruins commented on Jan 27, 2019

    @memoryruins
    Contributor

    ICEs occur on 1.31 and 1.30 as well. Previously, 1.29 produced the error.

    error[E0423]: expected function, found self type `Self`
      --> <source>:18:9
       |
    18 |         Self::<E>(Processor::<E>::new(key))
       |         ^^^^^^^^^ not a function
       |
       = note: can't use `Self` as a constructor, you must use the implemented struct
    
    error: aborting due to previous error
    
    For more information about this error, try `rustc --explain E0423`.
    
  4. memoryruins commented on Jan 27, 2019

    @memoryruins
    Contributor

    cargo bisect rustc helped narrow the regression to nightly-2018-09-15

    edit: #53751 seems possible. there has been a bit of changes to the code since, including fixes to other ICEs dealing with Self (#56850).

  5. hellow554 commented on Feb 12, 2019

    @hellow554
    Contributor

    Minified:

    pub struct Gcm<E>(E);
    
    impl<E> Gcm<E> {
        pub fn crash(e: E) -> Self {
            Self::<E>(e)
        }
    }

    ICE does not happen with Self(e) in the crash function

  6. aoikonomopoulos commented on Mar 8, 2019

    @aoikonomopoulos

    Tried to figure out the root cause by creating a similar, but passing, test case (using Gcm instead of Self). Looking at the differences of the debug logs, I ended up in instantiate_value_path. AFAICT the issue seems to be that

    • the function builds path_segs starting from the Def of SelfCtor
    • it then switches to the def_id of the replacement StructCtor
    • it uses path_segs in the callback passed to create_substs_for_generic_args which then tries to look up the generic arguments starting from the new def_id

    Specifically, what I'm seeing is that, when starting out from SelfCtor, def_id_for_path_segments treats it just like StructCtor. I.e. it queries its generics (generics_of) and then uses the def_id of the parent, if available. SelfCtor doesn't have a parent[0], hence def_id_for_path_segments pushes the def_id of the Impl in the returned Vec.

    The Vec gets assigned to path_segs in the body of instantiate_value_path, which then (via impl_self_ty) resolves the SelfCtor to the StructCtor of the impl that Self refers to and assigns the DefId of the StructCtor to def_id.

    Later, it calls into create_substs_for_generic_args, giving it a callback that will look up the generic args by DefId. The def_id argument that it passes refers to the StructCtor, so the stack that is built is the same regardless of whether Self is used or not.

    The first element popped off the stack is DefId(0/0:3 ~ <cratename>[317d]::GcmX[0]) , which gets passed to the callback provided by instantiate_value_path. The callback tries to look up this DefId and fails (whereas it would succeed if we were not using Self).

    AFAIU, this is because we calculated path_segs starting from the Impl, but we're looking up the args_for_def_id using the parents of the StructCtor.

    I tried to move the part that rewrites the Def for Self earlier in the function (which also required moving the early exit for Local/Upvar to the beginning of the function) and this seems to fix this issue (and all tests still pass). However, as commit 2157958 that introduced the SelfCtor rewriting explicitly placed it right before the call to create_substs_for_generic_args, I'm unsure as to whether this is the most appropriate fix (or indeed a correct fix).

    [0] generics_of works with Nodes, there's no SelfCtor at that point.

  7. added a commit that references this issue on Mar 13, 2019
    ae5856f
  8. added a commit that references this issue on Mar 13, 2019
    d263029
  9. added a commit that references this issue on Mar 14, 2019
    d30cf00
  10. added a commit that references this issue on Mar 15, 2019
    05ad8ba
  11. added a commit that references this issue on Mar 16, 2019
    e45828c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions