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: Compiling Commingle project #77523

Closed
aknuds1 opened this issue Oct 4, 2020 · 4 comments · Fixed by #77591
Closed

ICE: Compiling Commingle project #77523

aknuds1 opened this issue Oct 4, 2020 · 4 comments · Fixed by #77591
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@aknuds1
Copy link

aknuds1 commented Oct 4, 2020

Code

git clone https://gitlab.com/commingle/commingle.git
git checkout 43b73938f4157bfb634bfeb175d1b02f5e6a4759
RUST_BACKTRACE=1 cargo run

Meta

rustc --version --verbose:

rustc 1.49.0-nightly (25c8c53dd 2020-10-03)
binary: rustc
commit-hash: 25c8c53dd994acb3f4f7c02fe6bb46076393f8b0
commit-date: 2020-10-03
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0

Error output

Compiling commingle v0.0.2 (/home/arve/Projects/commingle)
error: internal compiler error: compiler/rustc_ty/src/instance.rs:136:21: AssocItem { def_id: DefId(168:66 ~ web[c7a2]::get_index::{closure#0}::Render::__maud_render_to), ident: __maud_render_to#10509, kind: Fn, vis: Restricted(DefId(168:0 ~ web[c7a2])), defaultness: Default { has_value: true }, container: TraitContainer(DefId(168:65 ~ web[c7a2]::get_index::{closure#0}::Render)), fn_has_self_parameter: true } not found in DefId(168:67 ~ web[c7a2]::get_index::{closure#0}::{impl#0})
Backtrace

stack backtrace:
   0: std::panicking::begin_panic
   1: rustc_errors::HandlerInner::bug
   2: rustc_errors::Handler::bug
   3: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
   4: rustc_middle::ty::context::tls::with_opt::{{closure}}
   5: rustc_middle::ty::context::tls::with_opt
   6: rustc_middle::util::bug::opt_span_bug_fmt
   7: rustc_middle::util::bug::bug_fmt
   8: rustc_ty::instance::resolve_associated_item::{{closure}}
   9: rustc_ty::instance::inner_resolve_instance
  10: rustc_ty::instance::resolve_instance
  11: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::resolve_instance>::compute
  12: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  13: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  14: rustc_data_structures::stack::ensure_sufficient_stack
  15: rustc_query_system::query::plumbing::get_query_impl
  16: rustc_middle::ty::instance::Instance::resolve_opt_const_arg
  17: rustc_middle::ty::instance::Instance::resolve
  18: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc_middle::mir::visit::Visitor>::visit_terminator
  19: rustc_mir::monomorphize::collector::collect_neighbours
  20: rustc_mir::monomorphize::collector::collect_items_rec
  21: rustc_mir::monomorphize::collector::collect_items_rec
  22: rustc_mir::monomorphize::collector::collect_items_rec
  23: rustc_mir::monomorphize::collector::collect_items_rec
  24: rustc_mir::monomorphize::collector::collect_items_rec
  25: rustc_mir::monomorphize::collector::collect_items_rec
  26: rustc_mir::monomorphize::collector::collect_items_rec
  27: rustc_mir::monomorphize::collector::collect_items_rec
  28: rustc_mir::monomorphize::collector::collect_items_rec
  29: rustc_mir::monomorphize::collector::collect_items_rec
  30: rustc_mir::monomorphize::collector::collect_items_rec
  31: rustc_mir::monomorphize::collector::collect_items_rec
  32: rustc_mir::monomorphize::collector::collect_items_rec
  33: rustc_mir::monomorphize::collector::collect_items_rec
  34: rustc_mir::monomorphize::collector::collect_items_rec
  35: rustc_mir::monomorphize::collector::collect_items_rec
  36: rustc_mir::monomorphize::collector::collect_items_rec
  37: rustc_mir::monomorphize::collector::collect_items_rec
  38: rustc_mir::monomorphize::collector::collect_items_rec
  39: rustc_mir::monomorphize::collector::collect_items_rec
  40: rustc_mir::monomorphize::collector::collect_items_rec
  41: rustc_mir::monomorphize::collector::collect_items_rec
  42: rustc_mir::monomorphize::collector::collect_items_rec
  43: rustc_mir::monomorphize::collector::collect_items_rec
  44: rustc_mir::monomorphize::collector::collect_items_rec
  45: rustc_mir::monomorphize::collector::collect_items_rec
  46: rustc_mir::monomorphize::collector::collect_items_rec
  47: rustc_mir::monomorphize::collector::collect_items_rec
  48: rustc_mir::monomorphize::collector::collect_items_rec
  49: rustc_mir::monomorphize::collector::collect_items_rec
  50: rustc_mir::monomorphize::collector::collect_items_rec
  51: rustc_mir::monomorphize::collector::collect_items_rec
  52: rustc_mir::monomorphize::collector::collect_items_rec
  53: rustc_mir::monomorphize::collector::collect_items_rec
  54: rustc_mir::monomorphize::collector::collect_items_rec
  55: rustc_mir::monomorphize::collector::collect_items_rec
  56: rustc_mir::monomorphize::collector::collect_items_rec
  57: rustc_mir::monomorphize::collector::collect_items_rec
  58: rustc_mir::monomorphize::collector::collect_items_rec
  59: rustc_mir::monomorphize::collector::collect_items_rec
  60: rustc_mir::monomorphize::collector::collect_items_rec
  61: rustc_mir::monomorphize::collector::collect_items_rec
  62: rustc_mir::monomorphize::collector::collect_items_rec
  63: rustc_mir::monomorphize::collector::collect_items_rec
  64: rustc_mir::monomorphize::collector::collect_items_rec
  65: rustc_mir::monomorphize::collector::collect_items_rec
  66: rustc_mir::monomorphize::collector::collect_items_rec
  67: rustc_mir::monomorphize::collector::collect_items_rec
  68: rustc_mir::monomorphize::collector::collect_items_rec
  69: rustc_mir::monomorphize::collector::collect_items_rec
  70: rustc_mir::monomorphize::collector::collect_items_rec
  71: rustc_mir::monomorphize::collector::collect_items_rec
  72: rustc_mir::monomorphize::collector::collect_items_rec
  73: rustc_mir::monomorphize::collector::collect_items_rec
  74: rustc_mir::monomorphize::collector::collect_items_rec
  75: rustc_mir::monomorphize::collector::collect_items_rec
  76: rustc_mir::monomorphize::collector::collect_items_rec
  77: rustc_mir::monomorphize::collector::collect_items_rec
  78: rustc_mir::monomorphize::collector::collect_items_rec
  79: rustc_mir::monomorphize::collector::collect_items_rec
  80: rustc_mir::monomorphize::collector::collect_items_rec
  81: rustc_mir::monomorphize::collector::collect_items_rec
  82: rustc_mir::monomorphize::collector::collect_items_rec
  83: rustc_mir::monomorphize::collector::collect_items_rec
  84: rustc_mir::monomorphize::collector::collect_items_rec
  85: rustc_mir::monomorphize::collector::collect_items_rec
  86: rustc_mir::monomorphize::collector::collect_items_rec
  87: rustc_mir::monomorphize::collector::collect_items_rec
  88: rustc_mir::monomorphize::collector::collect_items_rec
  89: rustc_mir::monomorphize::collector::collect_items_rec
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.49.0-nightly (25c8c53dd 2020-10-03) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

query stack during panic:
#0 [resolve_instance] resolving instance `<web::svg::Svg as web::get_index::{closure#0}::Render>::__maud_render_to`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: aborting due to previous error

@aknuds1 aknuds1 added C-bug Category: This is a bug. 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 Oct 4, 2020
@jonas-schievink jonas-schievink added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Oct 4, 2020
@estebank
Copy link
Contributor

estebank commented Oct 5, 2020

I believe this might be related to higiene. It seems like we might be doing something wrong in TyTcx::higienic_eq because if I remove that filter in Node::item the code compiles.

CC @petrochenkov

@estebank estebank added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Oct 5, 2020
@aknuds1
Copy link
Author

aknuds1 commented Oct 5, 2020

Thanks @estebank, would be great to see this fixed.

@Aaron1011
Copy link
Member

Minimized: https://github.com/Aaron1011/maud_bug

This issue seems to require the following setup:

  1. A (nightly-only) proc macro emitting tokens using def-site hygiene
  2. An async function that invokes said proc-macro
  3. A separate crate which triggers monomorphization of the body of the async function (e.g. actually tries to poll it)

My guess is that this is a bug in hygiene serialization, since the issue doesn't occur if the async function and poller are in the same crate. I'll continue to investigate

@Aaron1011
Copy link
Member

It looks like the issue occurs here:

/// Hygienically compares a use-site name (`use_name`) for a field or an associated item with
/// its supposed definition name (`def_name`). The method also needs `DefId` of the supposed
/// definition's parent/scope to perform comparison.
pub fn hygienic_eq(self, use_name: Ident, def_name: Ident, def_parent_def_id: DefId) -> bool {
// We could use `Ident::eq` here, but we deliberately don't. The name
// comparison fails frequently, and we want to avoid the expensive
// `normalize_to_macros_2_0()` calls required for the span comparison whenever possible.
use_name.name == def_name.name
&& use_name
.span
.ctxt()
.hygienic_eq(def_name.span.ctxt(), self.expansion_that_defined(def_parent_def_id))
}
fn expansion_that_defined(self, scope: DefId) -> ExpnId {
match scope.as_local() {
Some(scope) => self.hir().definitions().expansion_that_defined(scope),
None => ExpnId::root(),
}
}

With hygiene serialization, we may be comparing SyntaxContexts from a foreign crate. However, we don't serialize the expansion_that_defined data, so we'll always end up ExpnId::root() for foreign DefIds.

However, I don't really understand everything that's going on here ('adjusting' and 'normalizing' a SyntaxContext).

@Aaron1011 Aaron1011 added the requires-nightly This issue requires a nightly compiler in some way. label Oct 5, 2020
JohnTitor added a commit to JohnTitor/rust that referenced this issue Oct 6, 2020
…estebank

Record `expansion_that_defined` into crate metadata

Fixes rust-lang#77523

Now that hygiene serialization is implemented, we also need to record
`expansion_that_defined` so that we properly handle a foreign
`SyntaxContext`.
@bors bors closed this as completed in 8d11f90 Oct 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ requires-nightly This issue requires a nightly compiler in some way. 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.

4 participants