Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICE with main lang items #73584

Closed
benbrittain opened this issue Jun 21, 2020 · 1 comment · Fixed by #88782
Closed

ICE with main lang items #73584

benbrittain opened this issue Jun 21, 2020 · 1 comment · Fixed by #88782
Labels
A-lang-item Area: lang items C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@benbrittain
Copy link

Code

in library:

#[lang = "start"]                                                                                                                             
extern "C" fn start(main: fn(), _argc: isize, _argv: *const *const u8) -> isize {                                                             
    main();                                                                                                                                   
    0                                                                                                                                         
}                                                                                                                                             

in no_std binary:

fn main() {
...
}

This goes away if I turn on #![no_main] in the binary and annotate main with #[no_mangle].

Meta

rustc --version --verbose:

binary: rustc
commit-hash: f455e46eae1a227d735091091144601b467e1565
commit-date: 2020-06-20
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0

Error output

   Compiling rust-example v0.1.0 (/home/ben/workspace/nrf-test/rust-example)
error: internal compiler error: src/librustc_metadata/rmeta/decoder.rs:1106:17: get_optimized_mir: missing MIR for `DefId(4:22 ~ nrf52_sys[e357]::start[0])`

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:916:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:217
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
  12: std::panicking::begin_panic
  13: rustc_errors::HandlerInner::bug
  14: rustc_errors::Handler::bug
  15: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
  16: rustc_middle::ty::context::tls::with_opt::{{closure}}
  17: rustc_middle::ty::context::tls::with_opt
  18: rustc_middle::util::bug::opt_span_bug_fmt
  19: rustc_middle::util::bug::bug_fmt
  20: rustc_metadata::rmeta::decoder::<impl rustc_metadata::creader::CrateMetadataRef>::get_optimized_mir::{{closure}}
  21: rustc_metadata::rmeta::decoder::<impl rustc_metadata::creader::CrateMetadataRef>::get_optimized_mir
  22: rustc_metadata::rmeta::decoder::cstore_impl::provide_extern::optimized_mir
  23: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::optimized_mir>::compute
  24: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  25: rustc_data_structures::stack::ensure_sufficient_stack
  26: rustc_query_system::query::plumbing::get_query_impl
  27: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::instance_mir
  28: rustc_mir::monomorphize::collector::collect_neighbours
  29: rustc_data_structures::stack::ensure_sufficient_stack
  30: rustc_mir::monomorphize::collector::collect_items_rec
  31: rustc_mir::monomorphize::collector::collect_crate_mono_items
  32: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  33: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::collect_and_partition_mono_items>::compute
  34: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  35: rustc_data_structures::stack::ensure_sufficient_stack
  36: rustc_query_system::query::plumbing::get_query_impl
  37: rustc_codegen_ssa::base::codegen_crate
  38: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  39: rustc_interface::passes::start_codegen
  40: rustc_middle::ty::context::tls::enter_global
  41: rustc_interface::queries::Queries::ongoing_codegen
  42: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  43: rustc_span::with_source_map
  44: rustc_interface::interface::run_compiler_in_existing_thread_pool
  45: scoped_tls::ScopedKey<T>::set
  46: rustc_ast::attr::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.46.0-nightly (f455e46ea 2020-06-20) running on x86_64-unknown-linux-gnu

note: compiler flags: -C panic=abort -C embed-bitcode=no -C debuginfo=2 -C linker=arm-none-eabi-gcc -C link-arg=-mthumb -C link-arg=-Tnrf52.ld -C link-arg=-mcpu=cortex-m4 -C link-arg=--specs=nano.specs -C link-arg=-Wl,--gc-sections -C link-arg=-Wl,--start-group -C link-arg=-Wl,--end-group -C link-arg=-Wl,--build-id=none -C link-arg=-mabi=aapcs -C link-arg=-mfloat-abi=hard -C link-arg=-mfpu=fpv4-sp-d16 --crate-type bin

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

query stack during panic:
#0 [optimized_mir] optimizing MIR for `nrf52_sys::start`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack

@benbrittain benbrittain added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 21, 2020
@jonas-schievink jonas-schievink added the A-lang-item Area: lang items label Jun 21, 2020
@RalfJung RalfJung added the requires-nightly This issue requires a nightly compiler in some way. label Jun 24, 2020
@RalfJung
Copy link
Member

FWIW, when a lang item is used incorrectly, ICEs are expected. The standard library is the only code that is ever expected to define lang items, and if those are wrong then an ICE is appropriate.

Better errors are nice, but no attempt is made to actually be exhaustive about that.

Manishearth added a commit to Manishearth/rust that referenced this issue Sep 14, 2021
Fix ICE when `start` lang item has wrong generics

In my previous pr rust-lang#87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates.  This fixes that by updating the requirement to be exactly one generic type.

The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it.  I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations.  Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.

Fixes rust-lang#79559, fixes rust-lang#73584, fixes rust-lang#83117 (all duplicates)
Relevant to rust-lang#9307

r? ``@cjgillot``
ehuss added a commit to ehuss/rust that referenced this issue Sep 30, 2021
Fix ICE when `start` lang item has wrong generics

In my previous pr rust-lang#87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates.  This fixes that by updating the requirement to be exactly one generic type.

The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it.  I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations.  Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.

Fixes rust-lang#79559, fixes rust-lang#73584, fixes rust-lang#83117 (all duplicates)
Relevant to rust-lang#9307

r? `@cjgillot`
Manishearth added a commit to Manishearth/rust that referenced this issue Sep 30, 2021
Fix ICE when `start` lang item has wrong generics

In my previous pr rust-lang#87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates.  This fixes that by updating the requirement to be exactly one generic type.

The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it.  I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations.  Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.

Fixes rust-lang#79559, fixes rust-lang#73584, fixes rust-lang#83117 (all duplicates)
Relevant to rust-lang#9307

r? ``@cjgillot``
Manishearth added a commit to Manishearth/rust that referenced this issue Sep 30, 2021
Fix ICE when `start` lang item has wrong generics

In my previous pr rust-lang#87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates.  This fixes that by updating the requirement to be exactly one generic type.

The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it.  I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations.  Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.

Fixes rust-lang#79559, fixes rust-lang#73584, fixes rust-lang#83117 (all duplicates)
Relevant to rust-lang#9307

r? ```@cjgillot```
@bors bors closed this as completed in 3d86aac Oct 1, 2021
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 7, 2021
Fix ICE when `start` lang item has wrong generics

In my previous pr rust-lang#87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates.  This fixes that by updating the requirement to be exactly one generic type.

The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it.  I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations.  Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.

Fixes rust-lang#79559, fixes rust-lang#73584, fixes rust-lang#83117 (all duplicates)
Relevant to rust-lang#9307

r? ````@cjgillot````
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lang-item Area: lang items C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants