Expend syntax::with_globals coverage and allow nested calls #53526

earthengine · Aug 20, 2018

#53448 (and proberly #53469) is partialy fixed in the sense the error messages, if any, will be shown as

error: internal compiler error: broken MIR in DefId(0/0:7 ~ hrtb_fn_parameters[317d]::main[0]) (_7 = &mut (*_2)): bad assignment (&mut dyn std::ops::FnMut(()) = &mut dyn std::ops::FnMut(<() as Lt<'_>>::T)): NoSolution
  --> F:\work\rust\rust_git\rust\src/test\run-pass\hrtb-fn-parameters.rs:23:5
   |
23 |     f(v);
   |     ^

rather than "cannot access a scoped thread local variable without calling set first".

Problem analysis

run_compiler function is wrapped by a syntax::with_globals call to ensure it have access to syntax::GLOBALS. However, as we have code after running run_compile requires to emit errors, when it needs to show the position of the error, it will panic as syntax::GLOBALS is unavailable.

This pull request fixed this by introducing a new call to syntax::with_globals in run. So code in run will use bigger syntax::with_globals coverage than other calls to run_compiler.

It also makes calling syntax::with_globals when it is already called in the outside code uses the already initialized globals, rather than creating new instances.

Although this does not actually fix #53448 nor #53469, it will make similar errors never hide the useful error message any more, and so will help diagnosis simular situations easier.

My very first pull request on the compiler ever. Please advise me if I did anything wrong.

rust-highfive · Aug 20, 2018

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @petrochenkov (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

rust-highfive · Aug 20, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:53:21] ....................................................................................................
[00:53:24] ....................................................................................................
[00:53:27] ......i.............................................................................................
[00:53:30] ....................................................................................................
[00:53:32] .......................................................iiiiiiiii....................................
[00:53:38] ....................................................................................................
[00:53:42] ....................................................................................................
[00:53:45] ....................................i...............................................................
[00:53:47] ......................................................................................i.i..ii.......
---
[00:58:38] ....................................................................................................
[00:58:52] ....................................................................................................
[00:59:07] ..........................................................ii........................................
[00:59:24] ....................i....i.....................................................i....................
[00:59:52] ...........................F........................................................................
[01:00:11] ....................................................................................................
[01:00:22] ....................................................................................................
[01:00:31] ..........................................................................
[01:00:31] failures:
[01:00:31] failures:
[01:00:31] 
[01:00:31] ---- [run-pass] run-pass/super-fast-paren-parsing.rs stdout ----
[01:00:31] 
[01:00:31] error: compilation failed!
[01:00:31] status: exit code: 101
[01:00:31] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/super-fast-paren-parsing.rs" "--target=x86_64-unknown-linux-gnu" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/super-fast-paren-parsing/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/super-fast-paren-parsing/auxiliary"
[01:00:31] ------------------------------------------
[01:00:31] 
[01:00:31] ------------------------------------------
[01:00:31] stderr:
[01:00:31] stderr:
[01:00:31] ------------------------------------------
[01:00:31] thread 'rustc' panicked at 'cannot access a scoped thread local variable without calling `set` first', /cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.2/src/lib.rs:186:9
[01:00:31] 
[01:00:31] error: internal compiler error: unexpected panic
[01:00:31] 
[01:00:31] note: the compiler unexpectedly panicked. this is a bug.
[01:00:31] note: the compiler unexpectedly panicked. this is a bug.
[01:00:31] 
[01:00:31] note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
[01:00:31] 
[01:00:31] note: rustc 1.30.0-dev running on x86_64-unknown-linux-gnu
[01:00:31] 
[01:00:31] note: compiler flags: -Z unstable-options -C prefer-dynamic -C rpath
[01:00:31] 
[01:00:31] ------------------------------------------
[01:00:31] 
[01:00:31] thread '[run-pass] run-pass/super-fast-paren-parsing.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:3189:9
---
[01:00:31] 
[01:00:31] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:497:22
[01:00:31] 
[01:00:31] 
[01:00:31] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-5.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "5.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:00:31] 
[01:00:31] 
[01:00:31] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:00:31] Build completed unsuccessfully in 0:11:21
[01:00:31] Build completed unsuccessfully in 0:11:21
[01:00:31] make: *** [check] Error 1
[01:00:31] Makefile:58: recipe for target 'check' failed
35328 ./.git/modules/src/libcompiler_builtins/modules
34916 ./obj/build/x86_64-unknown-linux-gnu/native/jemalloc/src
34832 ./obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps
34832 ./.git/modules/src/libcompiler_builtins/modules/compiler-rt
---
travis_time:end:22ac2df4:start=1534772673165503765,finish=1534772673173001974,duration=7498209
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1b75feaa
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:11de5f50
travis_time:start:11de5f50
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:01957170
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

petrochenkov · Aug 20, 2018

r? @Zoxc

rust-highfive · Aug 20, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:31] tidy error: /checkout/src/librustc_driver/lib.rs:463: trailing whitespace
[00:04:32] some tidy checks failed
[00:04:32] 
[00:04:32] 
[00:04:32] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:32] 
[00:04:32] 
[00:04:32] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:32] Build completed unsuccessfully in 0:00:51
[00:04:32] Build completed unsuccessfully in 0:00:51
[00:04:32] make: *** [tidy] Error 1
[00:04:32] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0b1864d2
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:03480d20:start=1534807399816875825,finish=1534807399825653926,duration=8778101
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0ac4ab30
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0995154e
travis_time:start:0995154e
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:199df850
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:19:12]    Compiling rustc_lint v0.0.0 (file:///checkout/src/librustc_lint)
[00:19:12]    Compiling rustc_codegen_utils v0.0.0 (file:///checkout/src/librustc_codegen_utils)
[00:19:32]    Compiling rustc_plugin v0.0.0 (file:///checkout/src/librustc_plugin)
[00:19:33]    Compiling rustc_resolve v0.0.0 (file:///checkout/src/librustc_resolve)
            sess.abort_if_errors();
[00:20:15] 482 | |             }
[00:20:15] 483 | |         }
[00:20:15]     | |_________^ expected (), found tuple
[00:20:15]     |
[00:20:15]     |
[00:20:15]     = note: expected type `()`
[00:20:15]                found type `(std::result::Result<(), _>, std::option::Option<_>)`
[00:20:15] 
o --extern rustc_passes=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_passes-9838343e2adbcee9.so --extern rustc_plugin=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_plugin-fd0079a3967183e9.so --extern rustc_privacy=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_privacy-5b0749a532338fe8.so --extern rustc_resolve=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_resolve-cc472b54563acd7d.so --extern rustc_save_analysis=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_save_analysis-cbe791ad1ac1ddea.so --extern rustc_target=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_target-20eb47b9c402fee3.so --extern rustc_traits=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_traits-b46bf5b3351d287f.so --extern rustc_typeck=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_typeck-a0e39128708a13f4.so --extern scoped_tls=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libscoped_tls-6a496b98b1d59ff3.rlib --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-8c9bc9ee6cc9592f.so --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnus || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:23321e97
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:43] tidy error: /checkout/src/librustc_driver/lib.rs:190: trailing whitespace
[00:04:44] some tidy checks failed
[00:04:44] 
[00:04:44] 
[00:04:44] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:44] 
[00:04:44] 
[00:04:44] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:44] Build completed unsuccessfully in 0:00:49
[00:04:44] Build completed unsuccessfully in 0:00:49
[00:04:44] Makefile:79: recipe for target 'tidy' failed
[00:04:44] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0013612c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:00320361:start=1534810653695035136,finish=1534810653701515196,duration=6480060
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:258a4988
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:06251bd4
travis_time:start:06251bd4
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:12e3ded2
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:18:00]    Compiling rustc_borrowck v0.0.0 (file:///checkout/src/librustc_borrowck)
[00:18:00]    Compiling rustc_lint v0.0.0 (file:///checkout/src/librustc_lint)
[00:18:00]    Compiling rustc_passes v0.0.0 (file:///checkout/src/librustc_passes)
[00:18:00]    Compiling rustc_codegen_utils v0.0.0 (file:///checkout/src/librustc_codegen_utils)
c/x86_64-unknown-linux-gnu/release/deps/librustc-3a367afe0d047d15.so --extern rustc_rayon=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_rayon-54bf4ce7e3ad2c0c.rlib --extern rustc_allocator=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_allocator-eb6cd30317e16463.so --extern rustc_borrowck=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_borrowck-098f1309e6d28626.so --extern rustc_codegen_utils=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_codegen_utils-5363640c388c5a10.so --extern rustc_data_structures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_data_structures-8b624a6d6082b2ff.so --extern rustc_errors=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_errors-89eed8215142aadd.so --extern rustc_incremental=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_incremental-7faeda193058e659.so --extern rustc_lint=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_lint-0cef63f92d175448.so --extern rustc_metadata=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_metadata-193234ff46e7dfc6.so --extern rustc_mir=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_mir-0d31b3db998f4b07.so --extern rustc_passes=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_passes-9838343e2adbcee9.so --extern rustc_plugin=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_plugin-fd0079a3967183e9.so --extern rustc_privacy=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_privacy-5b0749a532338fe8.so --extern rustc_resolve=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_resolve-cc472b54563acd7d.so --extern rustc_save_analysis=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_save_analysis-cbe791ad1ac1ddea.so --extern rustc_target=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_target-20eb47b9c402fee3.so --extern rustc_traits=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_traits-b46bf5b3351d287f.so --extern rustc_typeck=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_typeck-a0e39128708a13f4.so --extern scoped_tls=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libscoped_tls-6a496b98b1d59ff3.rlib --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-8c9bc9ee6cc9592f.so --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

earthengine · Aug 21, 2018

I am sorry but I am not in a computer that have the tools to compile right now; So I have to use Github to edit the code and let the bots to check the code. Maybe abusing the resource, but the other choice is to wait until night, and I just can't wait...

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:17:52]    Compiling rustc_passes v0.0.0 (file:///checkout/src/librustc_passes)
tax=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax-64bbe8e4870170a3.so --extern syntax_ext=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax_ext-29dfa988647839fa.so --extern syntax_pos=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax_pos-3b51f50aecba154c.so -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/backtrace-sys-6c2cab36846647d7/out -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/miniz-sys-3c585aa15bfc4e69/out` (exit code: 1)
[00:18:19] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" " jemalloc" "--manifest-path" "/checkout/src/rustc/Cargo.toml" "--message-format" "json"
[00:18:19] expected success, got: exit code: 101
[00:18:19] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1119:9
[00:18:19] travis_fold:end:stage0-rustc

[00:18:19] travis_time:end:stage0-rustc:start=1534813500527169022,finish=1534814260313494257,duration=759786325235


[00:18:19] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap build
[00:18:19] Build completed unsuccessfully in 0:13:33
[00:18:19] make: *** [all] Error 1
[00:18:19] Makefile:28: recipe for target 'all' failed
travis_time:end:153636260 .
1400088 ./obj/build
1177028 ./.git
1058596 ./src
794336 ./obj/build/x86_64-unknown-linux-gnu
---
149120 ./src/llvm-emscripten/test
148688 ./obj/build/bootstrap/debug/incremental
140868 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc
134256 ./obj/build/bootstrap/debug/incremental/bootstrap-1v3ifugz4t07z
134252 ./obj/build/bootstrap/debug/incremental/bootstrap-1v3ifugz4t07z/s-f41nic04cw-vjejem-1iplbejydu42a
103868 ./src/tools/lldb
102552 ./obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu
102548 ./obj/build/x8tins/modules
34916 ./obj/build/x86_64-unknown-linux-gnu/native/jemalloc/src
---
21116 ./.git/modules/src/tools/cargo/objects/pack
travis_time:end:0c776fcb:start=1534814260624132380,finish=1534814260972190967,duration=348058587
travis_fold:end:after_failure.1
travis_fold:start:after_failure.2
trav || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0d27c89c
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:52] tidy error: /checkout/src/libsyntax/lib.rs:105: trailing whitespace
[00:04:53] some tidy checks failed
[00:04:53] 
[00:04:53] 
[00:04:53] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:53] 
[00:04:53] 
[00:04:53] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:53] Build completed unsuccessfully in 0:00:48
[00:04:53] Build completed unsuccessfully in 0:00:48
[00:04:53] make: *** [tidy] Error 1
[00:04:53] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:024e379f
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:09ee14e1:start=1534814978458897053,finish=1534814978465563418,duration=6666365
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:12351b20
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1c300b94
travis_time:start:1c300b94
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:39729888
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:04:34] tidy error: /checkout/src/libsyntax/lib.rs:104: trailing whitespace
[00:04:35] some tidy checks failed
[00:04:35] 
[00:04:35] 
[00:04:35] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:35] 
[00:04:35] 
[00:04:35] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:35] Build completed unsuccessfully in 0:00:49
[00:04:35] Build completed unsuccessfully in 0:00:49
[00:04:35] make: *** [tidy] Error 1
[00:04:35] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1c356fc0
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:014260e0:start=1534816047114868476,finish=1534816047122994678,duration=8126202
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0bc0a0d8
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:152ae5ec
travis_time:start:152ae5ec
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:00cd1bd0
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:06:37] For more information about this error, try `rustc --explain E0308`.
[00:06:37] error: Could not compile `syntax`.
[00:06:37] 
[00:06:37] Caused by:
[00:06:37]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name syntax libsyntax/lib.rs --color always --error-format json --crate-type dylib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 -C metadata=64bbe8e4870170a3 -C extra-filename=-64bbe8e4870170a3 --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps --extern bitflags=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libbitflags-3907cba388d41ef0.rlib --extern log=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/liblog-b6c566856a1e65b9.rlib --extern rustc_data_structures=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_data_structures-8b624a6d6082b2ff.so --extern rustc_errors=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_errors-89eed8215142aadd.so --extern rustc_target=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/d60 ./obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib
52152 ./obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu
52148 ./obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib
51036 ./obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin
49356 ./src/llvm/test/CodeGen/X86

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

rust-highfive · Aug 21, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

[00:47:04] ....................................................................................................
[00:47:07] ....................................................................................................
[00:47:09] .......i............................................................................................
[00:47:12] ....................................................................................................
[00:47:15] ........................................................iiiiiiiii...................................
[00:47:20] ....................................................................................................
[00:47:24] ....................................................................................................
[00:47:26] .....................................i..............................................................
[00:47:29] .......................................................................................i.i..ii......
---
[00:51:56] ....................................................................................................
[00:52:08] ....................................................................................................
[00:52:21] .........................................................ii.........................................
[00:52:36] ....................i....i.....................................................i....................
[00:53:01] ...........................F........................................................................
[00:53:19] ....................................................................................................
[00:53:28] ....................................................................................................
travis_time:end:16b81764:start=1534817282918756167,finish=1534820500399228212,duration=3217480472045

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

earthengine · Aug 21, 2018

So I have to stop here. The test "super-fast-paren-parsing.rs" was failed and I have no idea. As the comment was talked about "big stack" maybe an issue about a slightly bigger call stack. Need to check in a real computer.

alexreg · Aug 21, 2018

How are you getting on with this, @earthengine? Let me know if you could use some help, as I'm quite keen to get this issue solved too. Once you're done, maybe r? @oli-obk or @eddyb.

earthengine · Aug 21, 2018

It is now passed the tests. So it should be fine now!

The problem seems to be that, when the compiler needs to spawn a new thread, as I used the unwrapped call for run, it will not be covered by the with_globals call. So I reverted the refactoring (because we don't need it any more; we always assume the wrapped run_compiler), and then the updated with_globals will ensure we don't overriding the old values in the main thread.

r? @oli-obk

oli-obk · Aug 22, 2018

Can you add the ICEing test from the issue as a regression test and squash the commits?

Other than that it looks fine to me, but it seems very band-aidy. Not sure who we can ping on this though.

Zoxc · Aug 22, 2018

This fix seems questionable to me, but I haven't looked at the issues yet.

earthengine · Aug 22, 2018

@oli-obk

As this is the very first pull request, I don't know what a "regression test" mean and how to do it properly.

I was thinking adding tests though; but any tests given will be fixed at some stage though, as the code is in a error detection/prevention branch, tests for the ICEs will be fixed and so the test will be no longer appropriate.

I can squash the commits though. Will be done tonight.

alexreg · Aug 22, 2018

@earthengine I think @oli-obk just means to add your test case from the issue (a minimal reproducible version) to src/tests/run-pass/ to make sure it builds fine now, that's all. You can see other files in that directory for examples.

earthengine · Aug 23, 2018

@alexreg

The point is that ICE was NOT fixed, yet (so the minimal reproducible cannot be put in run-pass, it have to be in compile-fail to pass the test, for now). This PR can only reduce it to another ICE with more specific error message and point to a proper code position. Tests like this will not last long, not after the ICE itself being fixed.

alexreg · Aug 23, 2018

@earthengine Okay. In that case wait until you (or whoever) fixes the ICE before adding the run-pass regression test. (Do you have any idea how to fix the ICE, for that matter?)

earthengine · Aug 23, 2018

The ICE is not in my scope right now. The scope of this PR is to give more precise detail about some panicking ICEs, and so it is not targeting any specific ICE.

For this reason, I don't think we should wait for any ICEs to be fixed, as it is helping addressing issues, not fixes them.

If we DO need a test, it will be like add a compiler option -Zforce-delay-span-bug and force a delay_span_bug to trigger similar ICEs. This will require a seperate PR for that option, and wait for it to be accepted, then write a test to cause the "cannot access a scoped thread local variable without calling set first" ICE, then we can see this PR actually fixes this.

(I don't even know when I can dig deep enough to address the actual ICEs, though)

Zoxc · Aug 23, 2018

I think the clean fix here is to change fn run to call with_globals instead of fn run_compiler. The uses of run_compiler outside a run closures would then need to do their own with_globals setup.

We might be able to test ICE output to check that we get the "correct" ICE with the ui tests.

earthengine · Aug 23, 2018

I think the clean fix here is to change fn run to call with_globals instead of fn run_compiler.

This is what I have tried but didn't work. The reason is that run_compiler will be run on other threads in some configurations (for example, the "super-fast-paren-parsing.rs" test requires a bigger stack size, so the compiler spawn a new thread to run run_compiler). In that case, with_globals will not be called in that thread, and so we still have trouble.

We might be able to test ICE output to check that we get the "correct" ICE with the ui tests.

Actually I did this in my own computer! It is just that I am not sure it is good to have that test in the code base, as they will not last long.

Zoxc · Aug 23, 2018

run is the function which may create a thread (in the monitor call), and we must call with_globals after that.

earthengine · Aug 23, 2018

This is what I thought. But then with_globals will be called on a new set of empty values, I am not sure this is good as this means in most cases the previous global settings will be reset.

Even the latest form of this PR didn't resolve this though; when the new thread being created, it will work on an irrelevant instance of the globals, and so the main thread will still only get the empty values. But it only happen when there is a need to spawn a new thread and so pretty limited.

So it seems to be that the proper fix, is find a way to transfer a initialized value to the with_globals call and return it after run_compiler? This will require making sure Globals is Send

earthengine · Aug 23, 2018

My commits is now squashed without modification.

oli-obk · Aug 26, 2018

I'm going to close this in favour of #53624 since it doesn't modify the globals themselves.

Thanks for pushing ahead on this issue!

rust-highfive assigned petrochenkov Aug 20, 2018

rust-highfive added the S-waiting-on-review label Aug 20, 2018

rust-highfive assigned Zoxc and unassigned petrochenkov Aug 20, 2018

earthengine changed the title ~~Move syntax::with_globals call from run_compiler to run~~ Move code from run to run_compiler for syntax::with_globals coverage Aug 20, 2018

earthengine changed the title ~~Move code from run to run_compiler for syntax::with_globals coverage~~ Refactoring run_compiler for different syntax::with_globals coverage Aug 21, 2018

earthengine referenced this pull request Aug 21, 2018
Closed
ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

earthengine changed the title ~~Refactoring run_compiler for different syntax::with_globals coverage~~ Expend syntax::with_globals coverage and allow nested calls Aug 21, 2018

rust-highfive assigned oli-obk and unassigned Zoxc Aug 21, 2018

Zoxc referenced this pull request Aug 23, 2018
Merged
Move with_globals setup from run_compiler to run #53624

Move syntax::with_globals call from run_compiler to run

Loading status checks…

b6f254b

earthengine force-pushed the earthengine:Fix_53448 branch from 7e683da to b6f254b Aug 23, 2018

oli-obk closed this Aug 26, 2018

rust-lang/rust

Join GitHub today

Expend syntax::with_globals coverage and allow nested calls #53526

Conversation

earthengine commented Aug 20, 2018 • edited

Problem analysis

rust-highfive assigned petrochenkov Aug 20, 2018

This comment has been minimized.

rust-highfive commented Aug 20, 2018

rust-highfive added the S-waiting-on-review label Aug 20, 2018

This comment was marked as resolved.

rust-highfive commented Aug 20, 2018

This comment has been minimized.

petrochenkov commented Aug 20, 2018

rust-highfive assigned Zoxc and unassigned petrochenkov Aug 20, 2018

earthengine changed the title Move syntax::with_globals call from run_compiler to run Move code from run to run_compiler for syntax::with_globals coverage Aug 20, 2018

This comment was marked as resolved.

rust-highfive commented Aug 20, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

earthengine changed the title Move code from run to run_compiler for syntax::with_globals coverage Refactoring run_compiler for different syntax::with_globals coverage Aug 21, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment was marked as resolved.

earthengine commented Aug 21, 2018 • edited

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment was marked as resolved.

rust-highfive commented Aug 21, 2018

This comment has been minimized.

earthengine commented Aug 21, 2018

earthengine referenced this pull request Aug 21, 2018

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

This comment has been minimized.

alexreg commented Aug 21, 2018

earthengine changed the title Refactoring run_compiler for different syntax::with_globals coverage Expend syntax::with_globals coverage and allow nested calls Aug 21, 2018

This comment has been minimized.

earthengine commented Aug 21, 2018 • edited

rust-highfive assigned oli-obk and unassigned Zoxc Aug 21, 2018

This comment has been minimized.

oli-obk commented Aug 22, 2018

This comment has been minimized.

Zoxc commented Aug 22, 2018

This comment has been minimized.

earthengine commented Aug 22, 2018 • edited

This comment has been minimized.

alexreg commented Aug 22, 2018

This comment has been minimized.

earthengine commented Aug 23, 2018 • edited

This comment has been minimized.

alexreg commented Aug 23, 2018

This comment has been minimized.

earthengine commented Aug 23, 2018 • edited

This comment has been minimized.

Zoxc commented Aug 23, 2018

This comment has been minimized.

earthengine commented Aug 23, 2018 • edited

This comment has been minimized.

Zoxc commented Aug 23, 2018

This comment has been minimized.

earthengine commented Aug 23, 2018

Zoxc referenced this pull request Aug 23, 2018

Move with_globals setup from run_compiler to run #53624

earthengine force-pushed the earthengine:Fix_53448 branch from 7e683da to b6f254b Aug 23, 2018

This comment has been minimized.

earthengine commented Aug 23, 2018

This comment has been minimized.

oli-obk commented Aug 26, 2018

oli-obk closed this Aug 26, 2018

bors added a commit that referenced this pull request Aug 27, 2018

earthengine commented Aug 20, 2018 •

edited

earthengine commented Aug 21, 2018 •

edited

earthengine commented Aug 21, 2018 •

edited

earthengine commented Aug 22, 2018 •

edited

earthengine commented Aug 23, 2018 •

edited

earthengine commented Aug 23, 2018 •

edited

earthengine commented Aug 23, 2018 •

edited

earthengine force-pushed the earthengine:Fix_53448 branch from `7e683da` to `b6f254b` Aug 23, 2018