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 when using #[lang = "start"] in a #[no_std] static library #83117

Closed
jeremydavis519 opened this issue Mar 14, 2021 · 1 comment · Fixed by #88782
Closed

ICE when using #[lang = "start"] in a #[no_std] static library #83117

jeremydavis519 opened this issue Mar 14, 2021 · 1 comment · Fixed by #88782
Labels
A-lang-item Area: lang items C-bug Category: This is a bug. glacier ICE tracked in rust-lang/glacier. 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.

Comments

@jeremydavis519
Copy link

Code

Reproducing the bug seems to require two crates.

Crate ice-test, file main.rs:

#![no_std]
#![feature(lang_items)]

extern crate ice_test_lib;

use core::panic::PanicInfo;

fn main() {}

#[panic_handler]
fn panic_handler(_: &PanicInfo) -> ! {
    loop {}
}

#[lang = "eh_personality"] fn eh_personality() {}

Crate ice-test-lib, file lib.rs:

#![no_std]
#![feature(lang_items)]

#[lang = "start"] fn start(_: *const u8, _: isize, _: *const *const u8) -> isize {
    0
}

I compiled using cargo build, and ice-test's Cargo.toml listed ice-test-lib as a dependency.

Meta

rustc --version --verbose:

rustc 1.52.0-nightly (acca81892 2021-03-13)
binary: rustc
commit-hash: acca818928654807ed3bc1ce0e97df118f8716c8
commit-date: 2021-03-13
host: x86_64-unknown-linux-gnu
release: 1.52.0-nightly
LLVM version: 12.0.0

Error output

error: internal compiler error: compiler/rustc_metadata/src/rmeta/decoder.rs:1157:17: get_optimized_mir: missing MIR for `DefId(4:4 ~ ice_test_lib[6871]::start)`

thread 'rustc' panicked at 'Box<Any>', /rustc/acca818928654807ed3bc1ce0e97df118f8716c8/library/std/src/panic.rs:59:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.52.0-nightly (acca81892 2021-03-13) running on x86_64-unknown-linux-gnu

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

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

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

thread 'rustc' panicked at 'Box<Any>', /rustc/acca818928654807ed3bc1ce0e97df118f8716c8/library/std/src/panic.rs:59:5
stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::bug
   3: rustc_errors::Handler::bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::bug_fmt
   7: rustc_metadata::rmeta::decoder::<impl rustc_metadata::creader::CrateMetadataRef>::get_optimized_mir
   8: rustc_metadata::rmeta::decoder::cstore_impl::provide_extern::optimized_mir
   9: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  10: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  11: rustc_data_structures::stack::ensure_sufficient_stack
  12: rustc_query_system::query::plumbing::force_query_with_job
  13: rustc_query_system::query::plumbing::get_query_impl
  14: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::optimized_mir
  15: rustc_middle::ty::<impl rustc_middle::ty::context::TyCtxt>::instance_mir
  16: rustc_mir::monomorphize::collector::collect_neighbours
  17: rustc_mir::monomorphize::collector::collect_items_rec
  18: rustc_session::utils::<impl rustc_session::session::Session>::time
  19: rustc_mir::monomorphize::collector::collect_crate_mono_items
  20: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  21: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::collect_and_partition_mono_items>::compute
  22: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
  23: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  24: rustc_data_structures::stack::ensure_sufficient_stack
  25: rustc_query_system::query::plumbing::force_query_with_job
  26: rustc_query_system::query::plumbing::get_query_impl
  27: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::collect_and_partition_mono_items
  28: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  29: rustc_interface::passes::QueryContext::enter
  30: rustc_interface::queries::Queries::ongoing_codegen
  31: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  32: rustc_span::with_source_map
  33: scoped_tls::ScopedKey<T>::set

@jeremydavis519 jeremydavis519 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 Mar 14, 2021
@JohnTitor JohnTitor added the A-lang-item Area: lang items label Mar 16, 2021
@rust-lang-glacier-bot rust-lang-glacier-bot added the glacier ICE tracked in rust-lang/glacier. label Mar 17, 2021
@asquared31415
Copy link
Contributor

Duplicate of #79559

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. glacier ICE tracked in rust-lang/glacier. 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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants