Rust: 'rustc' panicked at 'failed to lookup `SourceFile` in new context'

[manio]

Hi.
I did cargo build and suddenly this goes to my console:
``Compiling hard v0.1.0 (/home/manio/IdeaProjects/hard) error: cannot find attributeget` in this scope
--> src/webserver.rs:15:3
|
15 | #[get("//")]
| ^^^

warning: unused import: rocket
--> src/webserver.rs:4:5
|
4 | use rocket;
| ^^^^^^
|
= note: #[warn(unused_imports)] on by default

thread 'rustc' panicked at 'failed to lookup SourceFile in new context', src/librustc_middle/ty/query/on_disk_cache.rs:456:17
note: run with RUST_BACKTRACE=1 environment variable to display 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.44.0-nightly (6dee5f112 2020-04-06) running on x86_64-unknown-linux-gnu

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

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

error: aborting due to previous error

error: could not compile hard.

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

I gave it another try and this is the backtrace:
https://pastebin.com/JLQy9Ear

I am using today nightly. It was compiling fine before... anyway as I believe that the problem is with panic - I am reporting this bug.

[jonas-schievink]

Thanks for the report. Can you provide the source code needed to reproduce this?

[manio]

Sure, the exact code which I was trying to build is now here in this branch:
https://github.com/manio/hard/tree/rust-panic

[Catman155]

I got the exact same issue at the moment

edit:
cargo clean fixes it for me

[manio]

I also tested 'cargo clean' - and it also worked for me :)
no more this panic...

[jonas-schievink]

Do you remember the change that induced this bug? It looks like this is a problem with incremental compilation, so we'll need to find a change that triggers the issue.

[manio]

@jonas-schievink
I was compiling my project with stable rust version, but today I've started to play with Rocket, so I've added rocket crate and I also did:
rustup override set nightly
Maybe this was the trigger of this problem...

In the mean time I might also did:
rustup target add arm-unknown-linux-gnueabihf - but I am not 100% sure now :(

[jonas-schievink]

@manio I was more wondering about any changes to your code, not the toolchain. It's fine if you don't remember of course, but it would make it easier to track this bug down. Thanks!

[manio]

@jonas-schievink
Oh - that should be trivial as I am trying to commiting often :D
All changes I've done in the code (with switching from stable to nightly) has to be here in this commit:
https://github.com/manio/hard/commit/348cd8728478dcad7948a951ce8154101270f089
The code has errors if that matters.

[Catman155]

For me it happened after this. Also tried rocket, I set ‘rustup default nightly’ and successfully compiled and ran with ‘cargo run’. But I remembered you could override for single projects. So I did ‘rustup default stable’ and then rustup override set nightly. The when i did ‘cargo run’ it gave the error.

[manio]

@jonas-schievink
I was trying hard to get a simple steps to reproduce the problem from the start. So I cloned to an empty repo without rocket, compiled with stable, added rocket, trying to compile stable - got an error, switched to nightly and then it compiles fine instead of panic :(
I spent over hour trying to reproduce the problem with different scenarios, but unfortunately I cannot reproduce it anymore...
Every time it just compiled fine and doesn't panic like before :(
I am suspecting that the state of the target dir was in some strange state during the normal development process but I am unable to get into this state anymore...
Cargo clean definitely fixes this problem for me (it's a pity that I didn't make a backup of it before).
So all we now have it the above backtrace.
I am assuming that cargo clean is not affecting any "user-wide" files in home dir and only in project target dir.

If you are unable to fix it without reproducing the problem then I am ok with closing this issue. It's up to you, guys...

[mpskowron]

I got the exact same issue a moment ago. Cleaning has helped as well. It was happening only for 'cargo test' for me, 'cargo build' was working fine. It happened after adding constructor methods to simple 2 fields struct and changing one test to use them instead of standard struct creation. Unfortunately I cannot share the repo, since it is private.

[steffahn]

I got the exact same issue a moment ago. Cleaning has helped as well. It was happening only for 'cargo test' for me, 'cargo build' was working fine. It happened after adding constructor methods to simple 2 fields struct and changing one test to use them instead of standard struct creation. Unfortunately I cannot share the repo, since it is private.

Are you by any chance able to reliably reproduce the error, though?

[mpskowron]

Just tried to go back and forth with my recent changes, but unfortunately I couldn't reproduce the error.

[gendx]

The error popped up for me as well (#71380), for example in the following Travis-CI build: https://travis-ci.org/github/tock/tock/builds/677725676

[steffahn]

Hmm, @gendx I can’t find anything indicating errors behind your ci build link, probably the information updated after a successful rebuild (indicating 37 minutes ago as of now), maybe I just don’t know where to look to get the log with an error. Furthermore, and in risk of repeating myself in this thread, but would you by any change be able to reproduce the panic somehow? Unfortunately, it seems to be a reoccurring theme around this bug that the error is surprisingly hard to reproduce after the cargo clean happened.

[gendx]

@steffahn indeed, a maintainer re-ran the Travis-CI build in the meantime (https://github.com/tock/tock/pull/1776#issuecomment-617231392), so it looks like the log is lost (from this link at least). I kept a snapshot of my filesystem in the state which triggered the crash.

Although I unfortunately can't share this snapshot of my filesystem, I can reproduce it (see my stack trace in https://github.com/rust-lang/rust/issues/71380).

One may have more luck to reproduce it with Tock, as it triggered already twice today (on my machine and on one of the Travis-CI builds).

---

Note: In the past, Tock already had some issues with a "bad" nightly version causing unexpected errors (although not an ICE) when the build cache was "dirty" (https://github.com/tock/tock/issues/1657). The process to reproduce this was the following.

# First, make sure to have a clean repo.
make clean  # i.e. cargo clean
# The first run works normally.
make ci-travis  # i.e. cargo build/test/etc
# Change a file to trigger a rebuild.
# No need to actually change anything, touching is enough.
touch kernel/src/debug.rs
# The second run triggers warnings/errors about `#[warn(unused_attributes)]`.
make ci-travis  # i.e. cargo build/test/etc

In the end we fixed it by upgrading from nightly-2020-02-27 to nightly-2020-03-06.

[gendx]

If that's of any help besides the stack trace and the source code (https://github.com/tock/tock/pull/1776/commits/0486784bfc80eea024b668788c6638efec4c0f4a), the following rustc commands failed. The directories /tock-ice/target/debug/incremental and /tock-ice/target/debug/deps contain the following files.

Failing rustc commands

Caused by: process didn't exit successfully: `rustc --crate-name cortexm4 --edition=2018 arch/cortex-m4/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C debuginfo=2 -C debug-assertions=on -C metadata=d9788ee5b1514791 -C extra-filename=-d9788ee5b1514791 --out-dir /tock-ice/target/debug/deps -C incremental=/tock-ice/target/debug/incremental -L dependency=/tock-ice/target/debug/deps --extern cortexm=/tock-ice/target/debug/deps/libcortexm-f71fceaed5328320.rmeta --extern kernel=/tock-ice/target/debug/deps/libkernel-60c37c9e254698ba.rmeta` (exit code: 101) warning: build failed, waiting for other jobs to finish... error: could not compile `cortexm4`. Caused by: process didn't exit successfully: `rustc --crate-name cortexm4 --edition=2018 arch/cortex-m4/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link -C debuginfo=2 --test -C metadata=4c759a83422cd560 -C extra-filename=-4c759a83422cd560 --out-dir /tock-ice/target/debug/deps -C incremental=/tock-ice/target/debug/incremental -L dependency=/tock-ice/target/debug/deps --extern cortexm=/tock-ice/target/debug/deps/libcortexm-f71fceaed5328320.rlib --extern kernel=/tock-ice/target/debug/deps/libkernel-60c37c9e254698ba.rlib` (exit code: 101)

target/debug/incremental/

$ ls target/debug/incremental/
arty_e21_chip-14ifyc0421f9
arty_e21_chip-1wxc13lq7cdn2
arty_e21_chip-29cems3ot9g7x
arty_e21_chip-2w2lb45245ly
arty_e21_chip-31pmlnlcm5285
arty_e21_chip-33itd10kp5liz
build_script_build-15fsbdyyy0snu
build_script_build-1slr11rp3bvdo
build_script_build-1vgep3mu1vic
build_script_build-1vtt2wq2rfea
build_script_build-255g3h9tvd5sv
build_script_build-2h4tvuo2tk9v7
build_script_build-2k0ngcnm9stxo
build_script_build-2ka1xkpj45rmp
build_script_build-2q6bogcn38xcw
build_script_build-3gkv2i1gm34hv
build_script_build-3ipdt1t9393rw
build_script_build-3ixnaewsqpihb
build_script_build-3oirbdgse0n3s
capsules-1200n3hpmbg6o
capsules-28wh29lq00ddb
capsules-3ge3497bpsol2
cc26x2-19yc8ajiw055x
cc26x2-20ngiq4vzu6ly
cc26x2-2aadv3nf3uf84
cc26x2-2eogkojfclus4
cc26x2-3hlkiuoykhvt7
cc26x2-96cbod9ue0qs
components-2ghtkhbl5329t
components-ejdfyvhcv2db
components-ksxdde0mv3ql
cortexm0-1btbakia9q09u
cortexm0-1ncz3nfugavhd
cortexm0-27xvauqzyqod5
cortexm0-2wk6hcozmdwel
cortexm0-3mxer6z2t10d8
cortexm0-8dybsllesl00
cortexm-1ak7kd3q70oqr
cortexm-2l9p7nb2dds6q
cortexm-2nns3hm6namsr
cortexm-2t3my3hw3wb46
cortexm3-284fdul5ndlfh
cortexm3-2x72dces31nwv
cortexm3-334yqlfociexy
cortexm3-3k568j7tg28ee
cortexm-3h0sp4x5kjby6
cortexm-3i7xi27uf3f3a
cortexm3-khhrpx7yg40
cortexm3-p1lx69gkfey3
cortexm4-1cetsv7btouni
cortexm4-1n9m8zcnh0w3l
cortexm4-1ubqgwq00x2cc
cortexm4-23uaza7g578mt
cortexm4-27z7t7qvfbo6d
cortexm4-30ubowmuyj9fd
cortexm4-fsc3ztrlpjyk
cortexm-ch8le07oegte
e310x-1rt1mkj4f9c9u
e310x-2gdlaxlc41lb3
e310x-2lm7oxdhalo7i
e310x-2wowuwgsw47it
e310x-mophx6iw5sl2
e310x-vloszx3xeezk
enum_primitive-1nh8exrbseugp
enum_primitive-2hwikfn648xn
enum_primitive-2j8bu25xtfzst
enum_primitive-2n5wqz4f56a7a
enum_primitive-351i37nkud6iq
ibex-15q9osu25dpg
ibex-18hepp9n7rrts
ibex-1xgj8owuh2fvd
ibex-2nk7k09detrf3
ibex-8qaof5fxns0h
ibex-9z4sl22brx8t
kernel-1jym1tx3n4lh8
kernel-1w08s222royu0
kernel-25mbdjb92meum
kernel-2sfv1kwx7teny
kernel-3kddx1qr9d99j
kernel-o39fp096pv51
lowrisc-1zzl8c2mfjj4i
lowrisc-27useaklolrv7
lowrisc-3559vi0xi1lum
lowrisc-3ddmmt2p45uha
lowrisc-3qp3uuffs1ibv
lowrisc-kty971qjenw
lowrisc-q65fu45l5vts
nrf52-27spta49wo18k
nrf52-2a0162cor5p7c
nrf52-2mys9yccd42t0
nrf52-3327aeodjy89z
nrf52-3mc1q2c79r8ol
nrf52832-1h36gpry2ow15
nrf52832-1n69k1sbq3z8a
nrf52832-2tnkcy97k5900
nrf52832-390g80jv2f3cn
nrf52832-tyhkehz1spuw
nrf52840-2lzqou8unakm0
nrf52840-3hnfvpb9agebo
nrf52840-goqb8qc21yzd
nrf52840-gxukz5gdgqui
nrf52840-irmbt4wc6blf
nrf52-g6y0i6qf8xg1
nrf5x-17kgr07npufol
nrf5x-1qsllzco0fn5j
nrf5x-2a5fquv72m6dl
nrf5x-2kuop486hpckp
nrf5x-2ypcq44tavlw9
nrf5x-3bi21jewx0jn4
nrf5x-3qc84a7ben5lw
nrf5x-3si0q71qjscka
nrf5x-kwfkvp7qz426
riscv_csr-1cs21nu5khbko
riscv_csr-1ra6g8gkyuvza
riscv_csr-2abrmnv68ql43
riscv_csr-2pkebtujngnj8
riscv_csr-3vtaw07pt0klw
rv32i-1f25g5lk6nxfa
rv32i-1nsmbxf4f1haq
rv32i-1r7uqhjaylixy
rv32i-3p4q93oqqwryr
rv32i-k6uvi5qzspcs
rv32i-qcvbe77spuvz
rv32i-tuo3wr0ra8c2
sam4l-161zg3v4sqj77
sam4l-1zp3p65xz22m1
sam4l-2xgk83f028x9h
sam4l-3prh0m6ynoen3
sam4l-9jxqqwmdy1kg
sam4l-gf2uez2316e8
sifive-1etvwp1y9rsf8
sifive-2d8dw8wrnp5zv
sifive-3bva0liu0a8ef
sifive-3fqi0lbjrlxpt
sifive-3sk30p21xwprn
sifive-3thv3zz6jj848
sifive-d78leorfbj2n
stm32f3xx-2n4kffgp2v0li
stm32f3xx-39qhemvnrhxlq
stm32f3xx-3q5k9qryw7o4x
stm32f3xx-m65nwfzq3z71
stm32f3xx-pff153lb4me8
stm32f3xx-ylzb9pw2nyo7
stm32f4xx-1124ywy7jq1st
stm32f4xx-2ub77ui4vs2rm
stm32f4xx-303n3f4ie6eco
stm32f4xx-30r6vmzfqb5sv
stm32f4xx-3bi1pzo0qqj50
stm32f4xx-pm8ae5538ub7
stm32f4xx-xwi3ucd5v5ta
tock_cells-1ja9beejppbjo
tock_cells-1n984rrrmcjv2
tock_cells-30ti5dt2xvo2j
tock_cells-3u82kieocxcio
tock_cells-9liucco56ywa
tock_cells-alblahang2v0
tock_cells-v9igk0queee4
tock_registers-12qi8mle4gn3r
tock_registers-1eb1jc0tp00yp
tock_registers-21zdmoz04dvds
tock_registers-25wqyt02qn4o2
tock_registers-2zmcaepof7728
tock_registers-5bi0jc849wwq
tock_registers-qv0xl70ft4pi
tock_rt0-12yc77d22owj9
tock_rt0-2xutdlfoeheke
tock_rt0-gp78a9qc6380
tock_rt0-kurojaa17v55
tock_rt0-z0qh00ow2za2
traitobj_list-17x8bmi1pgiri

target/debug/deps/

$ ls target/debug/deps/
arty_e21_chip-437f5b5e737ae31a.d
arty_e21_chip-7f22377db93a2d04
arty_e21_chip-7f22377db93a2d04.d
arty_e21_chip-94312be011d90612.d
arty_e21_chip-beca91bbb5585717.d
arty_e21_chip-d0b43fdc6e2c9a3e.d
arty_e21_chip-d635bbec196f14d2
arty_e21_chip-d635bbec196f14d2.d
capsules-55fc4af47c1f7268.d
capsules-8522da60a203e53c.d
capsules-93f0ae8fa1bc0156.d
cc26x2-12fa8cc6fd5dea3c
cc26x2-12fa8cc6fd5dea3c.d
cc26x2-3476d3a01db0783a.d
cc26x2-546cd631dae78509.d
cc26x2-874b3276449f8e09.d
cc26x2-c32b9179b4b465ef
cc26x2-c32b9179b4b465ef.d
cc26x2-f63c2048576b71e8.d
components-0a50d13774178c4d.d
components-125dc0ea68d80a20.d
components-7c648f76f5164f8b.d
cortexm0-2d3cc48e0590259d.d
cortexm0-48a20e198d8292b9
cortexm0-48a20e198d8292b9.d
cortexm0-5117954588969ffb.d
cortexm0-68b79deb2d51a1be.d
cortexm-0858efdd6db2c523.d
cortexm0-a063128a744c93dc.d
cortexm0-efd0e168bf645c59
cortexm0-efd0e168bf645c59.d
cortexm-210cf0b91f7ede48.d
cortexm3-20fe16b68d0a5a5a
cortexm3-20fe16b68d0a5a5a.d
cortexm3-586feddca5e846c6
cortexm3-586feddca5e846c6.d
cortexm3-6e42e9a5cd5c88e6.d
cortexm3-c148d75aa0691dbb.d
cortexm3-e506d057433d2337.d
cortexm3-f5c09445dc193c2c.d
cortexm4-1ab532e18dd9528c.d
cortexm4-4c759a83422cd560
cortexm4-4c759a83422cd560.d
cortexm4-7690283a52d03166.d
cortexm4-d90b20ec1b7fcddc.d
cortexm4-d9788ee5b1514791.d
cortexm4-eacd56e21e822c0e
cortexm4-eacd56e21e822c0e.d
cortexm4-ed289631f1372b51.d
cortexm-7dd51b541762561d
cortexm-7dd51b541762561d.d
cortexm-87a367413d5c4a63
cortexm-87a367413d5c4a63.d
cortexm-c58f4421a2fb1470.d
cortexm-f71fceaed5328320.d
cortexm-f89bb70db1b52e63.d
e310x-0f050a99c99450dc.d
e310x-165c086e46f71910.d
e310x-416a5697317ae4a3
e310x-416a5697317ae4a3.d
e310x-90e7c9ba8000dbae.d
e310x-95c29e9ce9aea807.d
e310x-c1f3e6888b35b801
e310x-c1f3e6888b35b801.d
enum_primitive-01deede54aa379fe.d
enum_primitive-511ec508b0ffd85a.d
enum_primitive-d298ef6cde0cef07.d
enum_primitive-dc25c2db58ad5d07.d
enum_primitive-fdc72b49ee620f7d.d
ibex-0d8643810f41d5cc.d
ibex-155d52ffefa1a321
ibex-155d52ffefa1a321.d
ibex-2bda4a8903b558c2.d
ibex-547d2fffdc91fb98.d
ibex-c97c1e7945543830
ibex-c97c1e7945543830.d
ibex-f056c52fb326a4fd.d
kernel-56b42acae370b1c5.d
kernel-60c37c9e254698ba.d
kernel-9c0a24b15d2ed898.d
kernel-a895906f97c73b5e.d
kernel-c7baf19ad407e676.d
kernel-e37a53f2efad794c
kernel-e37a53f2efad794c.d
libarty_e21_chip-437f5b5e737ae31a.rlib
libarty_e21_chip-437f5b5e737ae31a.rmeta
libarty_e21_chip-94312be011d90612.rmeta
libarty_e21_chip-beca91bbb5585717.rmeta
libarty_e21_chip-d0b43fdc6e2c9a3e.rlib
libarty_e21_chip-d0b43fdc6e2c9a3e.rmeta
libcapsules-55fc4af47c1f7268.rmeta
libcapsules-8522da60a203e53c.rmeta
libcapsules-93f0ae8fa1bc0156.rmeta
libcc26x2-3476d3a01db0783a.rlib
libcc26x2-3476d3a01db0783a.rmeta
libcc26x2-546cd631dae78509.rlib
libcc26x2-546cd631dae78509.rmeta
libcc26x2-874b3276449f8e09.rmeta
libcc26x2-f63c2048576b71e8.rmeta
libcomponents-0a50d13774178c4d.rmeta
libcomponents-125dc0ea68d80a20.rmeta
libcomponents-7c648f76f5164f8b.rmeta
libcortexm0-2d3cc48e0590259d.rlib
libcortexm0-2d3cc48e0590259d.rmeta
libcortexm0-5117954588969ffb.rmeta
libcortexm0-68b79deb2d51a1be.rlib
libcortexm0-68b79deb2d51a1be.rmeta
libcortexm-0858efdd6db2c523.rmeta
libcortexm0-a063128a744c93dc.rmeta
libcortexm-210cf0b91f7ede48.rlib
libcortexm-210cf0b91f7ede48.rmeta
libcortexm3-6e42e9a5cd5c88e6.rmeta
libcortexm3-c148d75aa0691dbb.rlib
libcortexm3-c148d75aa0691dbb.rmeta
libcortexm3-e506d057433d2337.rlib
libcortexm3-e506d057433d2337.rmeta
libcortexm3-f5c09445dc193c2c.rmeta
libcortexm4-1ab532e18dd9528c.rlib
libcortexm4-1ab532e18dd9528c.rmeta
libcortexm4-7690283a52d03166.rmeta
libcortexm4-d90b20ec1b7fcddc.rmeta
libcortexm4-d9788ee5b1514791.rmeta
libcortexm4-ed289631f1372b51.rmeta
libcortexm-c58f4421a2fb1470.rmeta
libcortexm-f71fceaed5328320.rlib
libcortexm-f71fceaed5328320.rmeta
libcortexm-f89bb70db1b52e63.rmeta
libe310x-0f050a99c99450dc.rmeta
libe310x-165c086e46f71910.rmeta
libe310x-90e7c9ba8000dbae.rlib
libe310x-90e7c9ba8000dbae.rmeta
libe310x-95c29e9ce9aea807.rlib
libe310x-95c29e9ce9aea807.rmeta
libenum_primitive-01deede54aa379fe.rmeta
libenum_primitive-511ec508b0ffd85a.rlib
libenum_primitive-511ec508b0ffd85a.rmeta
libenum_primitive-d298ef6cde0cef07.rmeta
libenum_primitive-dc25c2db58ad5d07.rmeta
libenum_primitive-fdc72b49ee620f7d.rlib
libenum_primitive-fdc72b49ee620f7d.rmeta
libibex-0d8643810f41d5cc.rlib
libibex-0d8643810f41d5cc.rmeta
libibex-2bda4a8903b558c2.rmeta
libibex-547d2fffdc91fb98.rmeta
libibex-f056c52fb326a4fd.rlib
libibex-f056c52fb326a4fd.rmeta
libkernel-56b42acae370b1c5.rmeta
libkernel-60c37c9e254698ba.rlib
libkernel-60c37c9e254698ba.rmeta
libkernel-9c0a24b15d2ed898.rmeta
libkernel-a895906f97c73b5e.rlib
libkernel-a895906f97c73b5e.rmeta
libkernel-c7baf19ad407e676.rmeta
liblowrisc-54a334eafa67b6f0.rmeta
liblowrisc-5ec6bd4456f62f5b.rlib
liblowrisc-5ec6bd4456f62f5b.rmeta
liblowrisc-798a818bfe77834e.rlib
liblowrisc-798a818bfe77834e.rmeta
liblowrisc-945523dcdc6ba860.rmeta
liblowrisc-ee031a5efdf6b384.rmeta
libnrf52-19495c3f415c1fad.rmeta
libnrf52832-098edb54ec1c725f.rlib
libnrf52832-098edb54ec1c725f.rmeta
libnrf52832-2a80ca02bef1fb17.rmeta
libnrf52832-793cb511573456d4.rlib
libnrf52832-793cb511573456d4.rmeta
libnrf52840-2ab43407ed21e1f1.rlib
libnrf52840-2ab43407ed21e1f1.rmeta
libnrf52840-44fadb63e6cfe33f.rlib
libnrf52840-44fadb63e6cfe33f.rmeta
libnrf52840-b96eb3fe8c28d721.rmeta
libnrf52-be2e9612abfbf25a.rmeta
libnrf52-c70eb80d2bfe3303.rmeta
libnrf52-e2360c9ac2dc0ad3.rlib
libnrf52-e2360c9ac2dc0ad3.rmeta
libnrf5x-1a5bfb4e57926522.rmeta
libnrf5x-32b207cd619a720f.rlib
libnrf5x-32b207cd619a720f.rmeta
libnrf5x-40f75bb9e1253fdf.rlib
libnrf5x-40f75bb9e1253fdf.rmeta
libnrf5x-49e49675350eae2e.rmeta
libnrf5x-49ffd99086904954.rlib
libnrf5x-49ffd99086904954.rmeta
libnrf5x-82540964f3eb2b08.rmeta
libnrf5x-cebe7101d8277281.rlib
libnrf5x-cebe7101d8277281.rmeta
libriscv_csr-16319ec0c6da4cf8.rmeta
libriscv_csr-37729e256701fadf.rmeta
libriscv_csr-49b72b85682c03a2.rmeta
libriscv_csr-7024c3b8955d8985.rlib
libriscv_csr-7024c3b8955d8985.rmeta
libriscv_csr-7d7f159483f54053.rlib
libriscv_csr-7d7f159483f54053.rmeta
librv32i-08d8b9e748bc5d32.rmeta
librv32i-4a66f82b8415f165.rmeta
librv32i-4c17b9e178388cc1.rlib
librv32i-4c17b9e178388cc1.rmeta
librv32i-51a9033551073700.rmeta
librv32i-9389ea65889d051b.rlib
librv32i-9389ea65889d051b.rmeta
libsam4l-16acd338831e77db.rlib
libsam4l-16acd338831e77db.rmeta
libsam4l-2558f9f18aec7c87.rlib
libsam4l-2558f9f18aec7c87.rmeta
libsam4l-2ca88d1e09bae65e.rmeta
libsam4l-5055e2d206880f08.rmeta
libsifive-033c4141d05b7794.rmeta
libsifive-30a21e4960a381d0.rlib
libsifive-30a21e4960a381d0.rmeta
libsifive-414429b7ebfcaac8.rlib
libsifive-414429b7ebfcaac8.rmeta
libsifive-622b56548507668f.rmeta
libsifive-e2d06b5611ebdd22.rmeta
libstm32f3xx-002a7d4529d87f6c.rlib
libstm32f3xx-002a7d4529d87f6c.rmeta
libstm32f3xx-0cbcf6b1eb5513f7.rlib
libstm32f3xx-0cbcf6b1eb5513f7.rmeta
libstm32f3xx-27cdc9e417b03ea9.rmeta
libstm32f3xx-abc0a0121a4b1cae.rmeta
libstm32f4xx-29a2c0c9af4fa609.rlib
libstm32f4xx-29a2c0c9af4fa609.rmeta
libstm32f4xx-9286458743416db1.rlib
libstm32f4xx-9286458743416db1.rmeta
libtock_cells-0f6973fce9cf4883.rlib
libtock_cells-0f6973fce9cf4883.rmeta
libtock_cells-186f8cadbb05ce48.rlib
libtock_cells-186f8cadbb05ce48.rmeta
libtock_cells-315f5ab7555ec6eb.rmeta
libtock_cells-5e6db09bd99da0fb.rmeta
libtock_cells-76c9af7eb901075c.rmeta
libtock_registers-110aad74301ce224.rmeta
libtock_registers-5002772a7b9a9f0f.rmeta
libtock_registers-59c5613c3e745611.rlib
libtock_registers-59c5613c3e745611.rmeta
libtock_registers-a1b0d44ce0d7fead.rmeta
libtock_registers-ac6c32caf72b15e9.rlib
libtock_registers-ac6c32caf72b15e9.rmeta
libtock_rt0-06d39a413125e45b.rlib
libtock_rt0-06d39a413125e45b.rmeta
libtock_rt0-3771040c6da871a1.rlib
libtock_rt0-3771040c6da871a1.rmeta
libtock_rt0-62e329643cae1904.rmeta
libtock_rt0-8e0664cee973148b.rmeta
libtock_rt0-c94b366fb7e2e1c3.rmeta
lowrisc-54a334eafa67b6f0.d
lowrisc-5ec6bd4456f62f5b.d
lowrisc-798a818bfe77834e.d
lowrisc-945523dcdc6ba860.d
lowrisc-9fc2dfc60140adf2
lowrisc-9fc2dfc60140adf2.d
lowrisc-c68c0777c14d171c
lowrisc-c68c0777c14d171c.d
lowrisc-ee031a5efdf6b384.d
nrf52-19495c3f415c1fad.d
nrf52832-098edb54ec1c725f.d
nrf52832-2a80ca02bef1fb17.d
nrf52832-57451f868d565882
nrf52832-57451f868d565882.d
nrf52832-5abd9e0bc77fab18
nrf52832-5abd9e0bc77fab18.d
nrf52832-793cb511573456d4.d
nrf52840-2ab43407ed21e1f1.d
nrf52840-44fadb63e6cfe33f.d
nrf52840-b96eb3fe8c28d721.d
nrf52840-be8a2249cde98a91
nrf52840-be8a2249cde98a91.d
nrf52840-d5cd5c4a30250e7c
nrf52840-d5cd5c4a30250e7c.d
nrf52-98b0ccb9da93f14e
nrf52-98b0ccb9da93f14e.d
nrf52-be2e9612abfbf25a.d
nrf52-c70eb80d2bfe3303.d
nrf52-cbaa7921c161d11a
nrf52-cbaa7921c161d11a.d
nrf52-e2360c9ac2dc0ad3.d
nrf5x-1a5bfb4e57926522.d
nrf5x-2d8fd58d698e8be8
nrf5x-2d8fd58d698e8be8.d
nrf5x-32b207cd619a720f.d
nrf5x-40f75bb9e1253fdf.d
nrf5x-49e49675350eae2e.d
nrf5x-49ffd99086904954.d
nrf5x-79d98acb0e86c9d8
nrf5x-79d98acb0e86c9d8.d
nrf5x-82540964f3eb2b08.d
nrf5x-cebe7101d8277281.d
riscv_csr-16319ec0c6da4cf8.d
riscv_csr-37729e256701fadf.d
riscv_csr-49b72b85682c03a2.d
riscv_csr-7024c3b8955d8985.d
riscv_csr-7d7f159483f54053.d
rv32i-08d8b9e748bc5d32.d
rv32i-28394fc75d2a1ed8
rv32i-28394fc75d2a1ed8.d
rv32i-4a66f82b8415f165.d
rv32i-4c17b9e178388cc1.d
rv32i-51a9033551073700.d
rv32i-9389ea65889d051b.d
rv32i-e9955a06cac581d8
rv32i-e9955a06cac581d8.d
sam4l-16acd338831e77db.d
sam4l-2558f9f18aec7c87.d
sam4l-2ca88d1e09bae65e.d
sam4l-5055e2d206880f08.d
sam4l-86b8040b17ceb3e8
sam4l-86b8040b17ceb3e8.d
sam4l-a9a76749d14d74d9
sam4l-a9a76749d14d74d9.d
sifive-033c4141d05b7794.d
sifive-244f9cc736ac9460
sifive-244f9cc736ac9460.d
sifive-30a21e4960a381d0.d
sifive-414429b7ebfcaac8.d
sifive-622b56548507668f.d
sifive-bb018db2c0d6439e
sifive-bb018db2c0d6439e.d
sifive-e2d06b5611ebdd22.d
stm32f3xx-002a7d4529d87f6c.d
stm32f3xx-0cbcf6b1eb5513f7.d
stm32f3xx-27cdc9e417b03ea9.d
stm32f3xx-2ccfd4923275ed5a
stm32f3xx-2ccfd4923275ed5a.d
stm32f3xx-8440d53040df2405
stm32f3xx-8440d53040df2405.d
stm32f3xx-abc0a0121a4b1cae.d
stm32f4xx-10a7c96d47f4e009.d
stm32f4xx-29a2c0c9af4fa609.d
stm32f4xx-7334064a4a0fa30a.d
stm32f4xx-917dec30146981af.d
stm32f4xx-9286458743416db1.d
stm32f4xx-c044f3808ef9ab31
stm32f4xx-c044f3808ef9ab31.d
stm32f4xx-c7ea20d8253198d1
stm32f4xx-c7ea20d8253198d1.d
tock_cells-09b22b52b4604ea7
tock_cells-09b22b52b4604ea7.d
tock_cells-0f6973fce9cf4883.d
tock_cells-186f8cadbb05ce48.d
tock_cells-315f5ab7555ec6eb.d
tock_cells-5e6db09bd99da0fb.d
tock_cells-76c9af7eb901075c.d
tock_cells-ba7f4307be66ffde
tock_cells-ba7f4307be66ffde.d
tock_registers-0be56fbc54144c39
tock_registers-0be56fbc54144c39.d
tock_registers-110aad74301ce224.d
tock_registers-5002772a7b9a9f0f.d
tock_registers-59c5613c3e745611.d
tock_registers-a1b0d44ce0d7fead.d
tock_registers-ac6c32caf72b15e9.d
tock_registers-bdbbd46bfa824ad9
tock_registers-bdbbd46bfa824ad9.d
tock_rt0-06d39a413125e45b.d
tock_rt0-3771040c6da871a1.d
tock_rt0-62e329643cae1904.d
tock_rt0-8e0664cee973148b.d
tock_rt0-c94b366fb7e2e1c3.d

[steffahn]

Although I unfortunately can't share this snapshot of my filesystem, I can reproduce it (see my stack trace in #71380).

I see, one important open question however is: which steps are necessary, from a clean start, to get your target directory into the state that the error can happen? Is one/multiple update(s) of the rust nightly version involved? Do you need to do certain changes to certain code which influence things in incremental compilation? Both?

Or are you actually already saying “I can reproduce it” as in: you can reproduce (as in “recreate”) the snapshot (rather than: you can reproduce the error using the snapshot). My guess is, you were just saying the latter (in parentheses), as you otherwise probably would’ve already posted a similar list of reproduction steps as in your example of “issues with a "bad" nightly version causing unexpected errors”.

Interestingly, now that you mention it, I remember seeing some `#[warn(unused_attributes)]` warnings, too; that was while I was building old rustc versions incrementally, recently. I should try reproducing those and see if they still apply to current compilers.

[ppannuto]

@hudson-ayers you also ran into this right -- any chance your build is still around?

[hudson-ayers]

I just saw it on Travis also, it didn't happen on my local machine

[gendx]

I see, one important open question however is: which steps are necessary, from a clean start, to get your target directory into the state that the error can happen? Is one/multiple update(s) of the rust nightly version involved? Do you need to do certain changes to certain code which influence things in incremental compilation? Both?

Or are you actually already saying “I can reproduce it” as in: you can reproduce (as in “recreate”) the snapshot (rather than: you can reproduce the error using the snapshot). My guess is, you were just saying the latter (in parentheses), as you otherwise probably would’ve already posted a similar list of reproduction steps as in your example of “issues with a "bad" nightly version causing unexpected errors”.

Correct, I can reproduce the error using the snapshot, but I don't have the exact steps that led to it from the clean start. These steps were roughly (1) bump the nightly version in our rust-toolchain file, (2) try to compile and observe the new compilation warnings/errors (we use -D warnings on some of our targets) that appeared in the new version, (3) a few iterations of fixing the code + re-building (without clearing the cache).

Note: I don't know how related this is, but I also noticed that Cargo builds dependencies in an arbitrary order on each run, so even a step like cargo build is not necessarily reproducible (e.g. on the first run build dependency A then B, on the second run B then A).

Interestingly, now that you mention it, I remember seeing some #[warn(unused_attributes)] warnings, too; that was while I was building old rustc versions incrementally, recently. I should try reproducing those and see if they still apply to current compilers.

We observed it on nightly-2020-02-27 (with reproduction steps at https://github.com/tock/tock/issues/1657#issuecomment-595770739) and never on nightly-2020-03-06.

---

Even though there is no clear reproduction steps, what is clear from these errors is the stack trace. Isn't it actionable?

https://github.com/rust-lang/rust/blob/8926bb497d9b127eb318aea5aed0e745d8381591/src/librustc_middle/ty/query/on_disk_cache.rs#L456-L458

The error message (failed to lookup `SourceFile` in new context) is a bit enigmatic for someone unfamiliar with this code, but:

• Someone who wrote/maintains this part of the code probably understands it better than me. There appears to have been 31 contributors to the relevant file (https://github.com/rust-lang/rust/blame/8926bb497d9b127eb318aea5aed0e745d8381591/src/librustc_middle/ty/query/on_disk_cache.rs).
• Could the message be improved to include which "source file" it's referring to? Even if this wouldn't directly solve the issue, it could at least help understand the problem next time it arises (e.g. if it's a source file that was just modified), and guide us towards reproduction steps.

[josephlr]

We also hit this issue in Travis as part of: https://github.com/rust-random/getrandom/pull/142.

Link to the specific Build failure: https://travis-ci.org/github/rust-random/getrandom/jobs/679958058

[leo-lb]

Also got this here:

https://github.com/stjepang/smol/runs/636888803?check_suite_focus=true#step:11:100

Seems related to caching

[editicalu]

got a similar issue:
https://pastebin.com/f62vVFH2

I don't know what triggered it (and am not allowed to share the source), but cargo clean solved it.

[xy137]

got the same issue after using git reset --hard

it seems like cargo clean fixed it though

[spastorino]

We would need reproduction steps, maybe Cleanup Crew ICE-breakers can help here.

@rustbot ping cleanup

[rustbot]

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
[instructions] for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke

[steffahn]

I’m unhappy with the labeling of this issue. We neither want to minimize anything (needs-mcve) nor bisect anything yet (needs-bisection), instead what’s missing is a way to reproduce the bug. IMO this would need a different, possibly new label.

Perhaps, since a complete and verifiable example _is_ needed, so something like “needs-cve”, or is mcve meant like “minimal, yet still complete”? Then perhaps just “needs-example” or something (needs-ve is getting a bit short).

[ehuss]

I have a reproduction, not sure if it is the same thing other people are running into, but might give a clue.

If the source mapping of a file changes between builds, then the panic happens. One way to trigger this is to install (or remove) the rust-src component from rustup between builds.

1. cargo new foo
2. cd foo
3. cargo build
4. rustup component remove rust-src (or rustup component add rust-src if you haven't already downloaded it)
5. touch src/main.rs
6. cargo build

I bisected the regression to #69718. cc @arlosi @eddyb

[gendx]

I can confirm that in Tock (https://github.com/rust-lang/rust/issues/70924#issuecomment-617228202) we're doing rustup component add rust-src at some point during the build: https://github.com/tock/tock/blob/ba44dd690f2db52ab9c928975f85c34c1c6f5bea/boards/Makefile.common#L112

[arlosi]

I was able to reproduce the issue on both sides of #69718, so I think the biseciton may be off.

I bisected it to #70642. cc @Mark-Simulacrum @eddyb
c520802785e5f2b4312f1a364f53577d9a521815 => Pass
c53e4b38779c3c074ae571b8520ab08e5bb0b904 => ICE

After #70642, rustc internally remaps the paths to files in the standard library if they are present on disk.

When the path for a file changes, so does its StableSourceFileId, which is used to correlate SourceFiles between incremental compilation sessions.

I think incremental compilation serializes the mapping from StableSourceFileId to SourceFiles, and since the StableSourceFileId is no longer stable, we hit the ICE when doing the lookup in the new session.

[ehuss]

Ah, apologies @arlosi! I'm not sure what went wrong with my bisect script. I didn't notice those two PRs landed within a day of each other, else I would have looked closer. Thanks for taking a look!

[spastorino]

Assigning P-high as discussed as part of the Prioritization Working Group process and removing I-prioritize.

[spastorino]

From what I've quickly searched this is a stable to beta regression.

[spastorino]

This was discussed during today's weekly meeting. Removing I-nominated.

[Fishrock123]

I was also encountering this.

A git clean -fdx on my repo cleared out whatever the problem file was.

active toolchain
----------------

beta-x86_64-pc-windows-msvc (default)
rustc 1.44.0-beta.4 (02c25b359 2020-05-23)

A backtrace enclosed

`` thread 'rustc' panicked at 'failed to lookupSourceFilein new context', src\librustc_middle\ty\query\on_disk_cache.rs:456:17 stack backtrace: 0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt 1: core::fmt::write 2: <std::io::IoSliceMut as core::fmt::Debug>::fmt 3: std::panicking::take_hook 4: std::panicking::take_hook 5: rustc_driver::report_ice 6: std::panicking::rust_panic_with_hook 7: rust_begin_unwind 8: core::panicking::panic_fmt 9: core::option::expect_failed 10: <rustc_middle::ty::query::on_disk_cache::CacheDecoder as serialize::serialize::SpecializedDecoder<rustc_span::span_encoding::Span>>::specialized_decode 11: ZN12rustc_middle2ty111_DERIVE_rustc_data_structures_stable_hasher_HashStable_rustc_middle_ich_StableHashingContext_ctx_FOR_SymbolName159_$LT$impl$u20$rustc_data_structures..stable_hasher..HashStable$LT$rustc_middle..ich..hcx..StableHashingContext$GT$$u20$ 12: <rustc_middle::ty::query::on_disk_cache::CacheDecoder as serialize::serialize::SpecializedDecoder<rustc_span::span_encoding::Span>>::specialized_decode 13: <rustc_middle::ty::sty::TypeAndMut as core::fmt::Debug>::fmt 14: <rustc_middle::ty::sty::TypeAndMut as core::fmt::Debug>::fmt 15: ZN12rustc_middle2ty5query13on_disk_cache17__ty_decoder_impl214_$LT$impl$u20$serialize..serialize..SpecializedDecoder$LT$$RF$$u5b$$LP$rustc_middle..ty..Predicate$C$rustc_span..span_encoding..Span$RP$$u5d$$GT$$u20$for$u20$rustc_middle..ty..query..on_disk_ca 16: <rustc_typeck::check::op::Op as core::fmt::Debug>::fmt 17: <rustc_typeck::check::method::CandidateSource as core::fmt::Debug>::fmt 18: <rustc_typeck::variance::terms::InferredIndex as core::fmt::Debug>::fmt 19: <rustc_typeck::collect::CollectItemTypesVisitor as rustc_hir::intravisit::Visitor>::visit_item 20: <rustc_typeck::variance::terms::InferredIndex as core::fmt::Debug>::fmt 21: <rustc_typeck::check::method::suggest::UsePlacementFinder as rustc_hir::intravisit::Visitor>::visit_mod 22: <rustc_typeck::variance::terms::InferredIndex as core::fmt::Debug>::fmt 23: <rustc_typeck::check::upvar::InferBorrowKind as rustc_typeck::expr_use_visitor::Delegate>::mutate 24: <rustc_typeck::check::writeback::Resolver as rustc_middle::ty::fold::TypeFolder>::fold_const 25: <rustc_typeck::variance::terms::InferredIndex as core::fmt::Debug>::fmt 26: <rustc_typeck::variance::terms::InferredIndex as core::fmt::Debug>::fmt 27: <rustc_typeck::outlives::explicit::ExplicitPredicatesMap as core::fmt::Debug>::fmt 28: rustc_typeck::check_crate 29: rustc_interface::passes::QueryContext::print_stats 30: <rustc_ast_passes::node_count::NodeCounter as rustc_ast::visit::Visitor>::visit_attribute 31: rustc_driver::pretty::print_after_hir_lowering 32: rustc_driver::pretty::print_after_hir_lowering 33: <rustc_ast_passes::node_count::NodeCounter as rustc_ast::visit::Visitor>::visit_attribute 34: rustc_driver::pretty::print_after_hir_lowering 35: rustc_driver::pretty::print_after_hir_lowering 36: <rustc_typeck::collect::ItemCtxt as rustc_typeck::astconv::AstConv>::re_infer 37: <rustc_typeck::collect::ItemCtxt as rustc_typeck::astconv::AstConv>::re_infer 38: <rustc_ast_passes::node_count::NodeCounter as rustc_ast::visit::Visitor>::visit_attribute 39: rustc_driver::pretty::print_after_hir_lowering 40: std::sys::windows::thread::Thread::new 41: BaseThreadInitThunk 42: RtlUserThreadStart note: Some details are omitted, run withRUST_BACKTRACE=full` for a verbose 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.44.0-beta.4 (02c25b359 2020-05-23) running on x86_64-pc-windows-msvc

note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

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

query stack during panic:

0 [predicates_of] processing <request::Request<State> as std::fmt::Debug>

1 [collect_mod_item_types] collecting item types in module request

2 [analysis] running analysis passes on this crate

end of query stack
```"

[pnkfelix]

After discussing with @eddyb , I have managed to replicate this on a local rustc build, and have a plausible fix in a prototype branch. Will be posting soon.