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

thread 'main' panicked at 'internal error: entered unreachable code', src/tools/tidy/src/pal.rs:224:9 #60505

Open
glandium opened this issue May 3, 2019 · 4 comments

Comments

Projects
None yet
5 participants
@glandium
Copy link
Contributor

commented May 3, 2019

Adding some #[cfg()] with unbalanced parens in some file in the rust directory makes python x.py build fail with the following error and backtrace:

thread 'main' panicked at 'internal error: entered unreachable code', src/tools/tidy/src/pal.rs:224:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::begin_panic
   6: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
   7: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
   8: tidy::pal::check::{{closure}}
   9: tidy::walk
  10: tidy::walk
  11: tidy::pal::check
  12: tidy::main
  13: std::rt::lang_start::{{closure}}
  14: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  15: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  16: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  17: main
  18: __libc_start_main
  19: _start

Which is rather unhelpful.

@hellow554

This comment has been minimized.

Copy link
Contributor

commented May 3, 2019

Looking at

cfgs.map(|i| {
let mut depth = 0;
let contents_from = &contents[i..];
for (j, byte) in contents_from.bytes().enumerate() {
match byte {
b'(' => {
depth += 1;
}
b')' => {
depth -= 1;
if depth == 0 {
return (i, &contents_from[..=j]);
}
}
_ => { }
}
}
unreachable!()
}).collect()

means, that unreachable should be

panic!("An uneven amount of `(` and `)` has been discovered")

(or similar)

If that wording is okay, I would go and file a PR

@varkor

This comment has been minimized.

Copy link
Member

commented May 3, 2019

Rather than panicking, it would be better to throw an error (e.g. using tidy_error!).
(I think unbalanced parentheses in `#[cfg]` would read slightly better.)

@glandium

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2019

Note that there are other cases where there is an error message like:

    |
207 | #[cfg(not(stage0)]
    |  -   -           ^ incorrect close delimiter
    |  |   |
    |  |   un-closed delimiter
    |  close delimiter possibly meant for this

It seems like we should get the same here too.

Edit: Come to think of it, this one might be coming from the compiler.

@varkor

This comment has been minimized.

Copy link
Member

commented May 3, 2019

We could just ignore #[cfg]s with unbalanced parentheses in tidy, as they'll be picked up during compilation. In that case, removing the unreachable!() and adding a comment to that effect should be enough.

@Centril Centril added I-ICE A-rustbuild and removed I-ICE labels May 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.