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

ICE: <type> was a subtype of <type> but now is not? #59406

Closed
OddCoincidence opened this issue Mar 25, 2019 · 2 comments · Fixed by #60721
Closed

ICE: <type> was a subtype of <type> but now is not? #59406

OddCoincidence opened this issue Mar 25, 2019 · 2 comments · Fixed by #60721
Labels
I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@OddCoincidence
Copy link
Contributor

I got this pretty weird ICE while in the middle of a refactor.

\error[E0624]: method `count` is private
   --> vm/src/obj/objrange.rs:115:41
    |
115 |         "count" => context.new_rustfunc(PyRangeRef::count),
    |                                         ^^^^^^^^^^^^^^^^^

error: internal compiler error: src/librustc_typeck/check/mod.rs:5549: instantiate_value_path: (UFCS) pyobject::PyRef<obj::objrange::PyRange> was a subtype of pyobject::PyRef<obj::objlist::PyList> but now is not?
   --> vm/src/obj/objrange.rs:115:41
    |
115 |         "count" => context.new_rustfunc(PyRangeRef::count),
    |                                         ^^^^^^^^^^^^^^^^^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:526: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
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:482
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::span_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::span_bug_fmt
  14: rustc_typeck::check::FnCtxt::instantiate_value_path
  15: rustc_typeck::check::FnCtxt::check_expr_kind
  16: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  17: rustc_typeck::check::FnCtxt::check_argument_types
  18: rustc_typeck::check::FnCtxt::check_method_argument_types
  19: rustc_typeck::check::FnCtxt::check_expr_kind
  20: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  21: rustc_typeck::check::FnCtxt::check_argument_types
  22: rustc_typeck::check::FnCtxt::check_method_argument_types
  23: rustc_typeck::check::FnCtxt::check_expr_kind
  24: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  25: rustc_typeck::check::FnCtxt::check_stmt
  26: rustc_typeck::check::FnCtxt::check_block_with_expected
  27: rustc_typeck::check::FnCtxt::check_expr_kind
  28: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  29: rustc_typeck::check::FnCtxt::check_return_expr
  30: rustc_typeck::check::check_fn
  31: rustc::ty::context::GlobalCtxt::enter_local
  32: rustc_typeck::check::typeck_tables_of
  33: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute
  34: rustc::dep_graph::graph::DepGraph::with_task_impl
  35: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_with
  36: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query
  37: rustc::session::Session::track_errors
  38: rustc_typeck::check::typeck_item_bodies
  39: rustc::ty::query::__query_compute::typeck_item_bodies
  40: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_item_bodies<'tcx>>::compute
  41: rustc::dep_graph::graph::DepGraph::with_task_impl
  42: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_get_with
  43: rustc::util::common::time
  44: rustc_typeck::check_crate
  45: <std::thread::local::LocalKey<T>>::with
  46: rustc::ty::context::TyCtxt::create_and_enter
  47: rustc_driver::driver::compile_input
  48: rustc_driver::run_compiler_with_pool
  49: <scoped_tls::ScopedKey<T>>::set
  50: rustc_driver::run_compiler
  51: <scoped_tls::ScopedKey<T>>::set
query stack during panic:
#0 [typeck_tables_of] processing `obj::objrange::init`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack
error: aborting due to 3 previous errors

I don't know how to turn this into a minimal example, so here's the offending code that reproduces this error: OddCoincidence/RustPython@836f267

@estebank
Copy link
Contributor

What version of the compiler are you using?

@estebank estebank added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 25, 2019
@OddCoincidence
Copy link
Contributor Author

$ rustc --version
rustc 1.33.0 (2aa4c46cf 2019-02-28)

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) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants