Stream: t-compiler/const-eval

Topic: PR sanity-query


RalfJ (Oct 26 2018 at 08:26, on Zulip):

@Oli when I locally build your sanity query PR, compiling stage1 compiler artifacts fails...

RalfJ (Oct 26 2018 at 08:26, on Zulip):
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:355:21rustc-demangle, rustc(build.rs)
note: Run with `RUST_BACKTRACE=1` for a backtrace.

error: internal compiler error: unexpected panic

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.31.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: -C opt-level=2 -C incremental --crate-type bin

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

error: Could not compile `rustc`.
warning: build failed, waiting for other jobs to finish...
error: build failed
oli (Oct 26 2018 at 08:26, on Zulip):

do you have a backtrace?

RalfJ (Oct 26 2018 at 08:27, on Zulip):
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: rustc::util::common::panic_hook
             at librustc/util/common.rs:51
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:480
   6: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   9: core::panicking::panic
             at libcore/panicking.rs:52
  10: rustc_typeck::check::wfcheck::check_impl_item
             at ./libcore/macros.rs:20
             at librustc_typeck/check/wfcheck.rs:172
  11: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::check_impl_item_well_formed<'tcx>>::compute
             at librustc/ty/query/plumbing.rs:826
  12: rustc::ty::context::tls::with_context
             at librustc/dep_graph/graph.rs:275
             at librustc/ty/context.rs:2018
             at librustc/ty/context.rs:1957
             at librustc/ty/context.rs:2017
             at librustc/dep_graph/graph.rs:274
             at librustc/ty/context.rs:2102
             at librustc/ty/context.rs:2093
             at librustc/ty/context.rs:2102
  13: rustc::dep_graph::graph::DepGraph::with_task_impl
             at librustc/dep_graph/graph.rs:268
  14: rustc::ty::context::tls::with_related_context
             at librustc/dep_graph/graph.rs:208
             at librustc/ty/query/plumbing.rs:550
             at librustc/ty/query/plumbing.rs:208
             at librustc/ty/context.rs:2018
             at librustc/ty/context.rs:1957
             at librustc/ty/context.rs:2017
             at librustc/ty/query/plumbing.rs:207
             at librustc/ty/context.rs:2118
             at librustc/ty/context.rs:2102
             at librustc/ty/context.rs:2093
             at librustc/ty/context.rs:2102
             at librustc/ty/context.rs:2113
  15: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
             at librustc/ty/query/plumbing.rs:197
             at librustc/ty/query/plumbing.rs:543
  16: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query
             at librustc/ty/query/plumbing.rs:621
  17: rustc::ty::query::plumbing::force_from_dep_node
             at librustc/ty/query/plumbing.rs:1199
RalfJ (Oct 26 2018 at 08:27, on Zulip):

seems like its an unwrap at wfcheck.rs:172

oli (Oct 26 2018 at 08:28, on Zulip):

https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/wfcheck.rs#L172

oli (Oct 26 2018 at 08:28, on Zulip):

O_o

oli (Oct 26 2018 at 08:33, on Zulip):

doesn't happen for me

oli (Oct 26 2018 at 08:33, on Zulip):

maybe I don't have test_miri on

oli (Oct 26 2018 at 08:34, on Zulip):

do you have the full backtrace with the query stack on the bottom?

RalfJ (Oct 26 2018 at 08:37, on Zulip):

I do have test-miri on indeed. not sure why that would make a difference here?

RalfJ (Oct 26 2018 at 08:38, on Zulip):

query stack is mixed with fancy cargo output...

query stack during panic:
   Compiling unreachable v1.0.0
#0 [check_impl_item_well_formed] processing `std`                     ] 30/110: rustc(build.rs), fmt_macros, rustc-serialize, rustc_platform_intrinsics, crossbeam-utils, log, arrayvec, unreachable
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
oli (Oct 26 2018 at 08:40, on Zulip):

So I'm thinking it could have to do with always-encode-mir, because parts of the compiler just don't cope well with having MIR available for everything. I think there are still parts that place some semantic value into the return value of is_mir_available

oli (Oct 26 2018 at 08:40, on Zulip):

but I have no clue how that could be during collect

oli (Oct 26 2018 at 08:41, on Zulip):

I'll do some debugging...

oli (Oct 26 2018 at 08:45, on Zulip):

nope I do have test-miri = true

oli (Oct 26 2018 at 08:45, on Zulip):

@RalfJ I have no clue what's going on, I can't repro

oli (Oct 26 2018 at 08:45, on Zulip):

do you have the full stacktrace so I can give a more educated guess?

RalfJ (Oct 26 2018 at 08:49, on Zulip):

sure but its just tons of query stuff

RalfJ (Oct 26 2018 at 08:49, on Zulip):

and it is too long for zulip...^^

oli (Oct 26 2018 at 08:49, on Zulip):

gist it?

RalfJ (Oct 26 2018 at 08:49, on Zulip):

https://paste.debian.net/1049096/

RalfJ (Oct 26 2018 at 08:49, on Zulip):

gists need a filename and a description

RalfJ (Oct 26 2018 at 08:50, on Zulip):

I always find that offputting

RalfJ (Oct 26 2018 at 08:50, on Zulip):

I will delete build/*/stage*, see if it makes a difference. you could try the same^^

RalfJ (Oct 26 2018 at 08:51, on Zulip):

here is my config.toml:

[llvm]
assertions = true
ninja = true
[build]
submodules = false
[rust]
debug-assertions = true
debuginfo-lines = true
incremental = true
test-miri = true
deny-warnings = false
oli (Oct 26 2018 at 08:53, on Zulip):

according to the stacktrace it's a call to Instance::resolve: https://github.com/rust-lang/rust/blob/master/src/librustc_mir/monomorphize/collector.rs#L1072

oli (Oct 26 2018 at 08:54, on Zulip):

for the start lang item !?

oli (Oct 26 2018 at 08:55, on Zulip):

it gets weirder: https://github.com/rust-lang/rust/blob/master/src/librustc/ty/instance.rs#L186

oli (Oct 26 2018 at 09:13, on Zulip):

stage 1 tests ran through successfully

RalfJ (Oct 26 2018 at 09:26, on Zulip):

@Oli odly I cannot reproduce either after clearing the stage* directories

oli (Oct 26 2018 at 09:26, on Zulip):

incremental bug I guess?

RalfJ (Oct 26 2018 at 09:26, on Zulip):

possible...

oli (Oct 26 2018 at 13:44, on Zulip):

Wheee! took two months, but the PR has been merged!

oli (Oct 26 2018 at 13:44, on Zulip):

I should just stop implementing features and just do refactorings

oli (Oct 26 2018 at 13:46, on Zulip):

it even only conflicted with one PR

oli (Oct 26 2018 at 13:56, on Zulip):

ah no, bors is just slow. it broke 1/3rd of the queue or so

RalfJ (Oct 29 2018 at 09:02, on Zulip):

yeah it did^^

RalfJ (Oct 29 2018 at 09:04, on Zulip):

but I am happy to see it landed :) sanity++

RalfJ (Oct 29 2018 at 09:07, on Zulip):

incremental bug I guess?

now seeing the same bug again. I still don't know how to reproduce it though...

RalfJ (Oct 29 2018 at 09:07, on Zulip):

with another PR, that is

RalfJ (Oct 29 2018 at 09:14, on Zulip):

I guess I will have to disable incremental again :(

oli (Oct 29 2018 at 09:22, on Zulip):

did you clean before you changed branches?

RalfJ (Oct 29 2018 at 09:52, on Zulip):

no, why would I?

RalfJ (Oct 29 2018 at 09:58, on Zulip):

See https://github.com/rust-lang/rust/issues/55463

oli (Oct 29 2018 at 10:01, on Zulip):

I always clean before I rebuild after a branch change as I have not been able to build rustc reliably otherwise

oli (Oct 29 2018 at 10:03, on Zulip):

mostly these have been duplicate crate errors during testing

RalfJ (Oct 29 2018 at 10:04, on Zulip):

without incremental I rarely have problems

Last update: Nov 15 2019 at 21:05UTC