Code change:
rustc --version; cat ; env RUSTBACKTRACE=1 rustc --emit asm --crate-type dylib -O --target thumbv7em-none-eabihf rustc 1.28.0-nightly ( 2018-05-21) #![nostd] pub fn pete() -u32 { 2 } warning: dropping unsupported crate type for target thread 'main' panicked at 'called on a value', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at at 2: std::panicking::defaulthook::{{closure}} at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panic at 10: rustccodegenllvm::base::writemetadata 11: rustc::util::common::time 12: rustccodegenllvm::base::codegencrate 13: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 14: rustc::util::common::time 15: rustcdriver::driver::phase4codegen 16: rustcdriver::driver::compileinput::{{closure}} 17: rustc::ty::context::tls::entercontext 18: <std::thread::local::LocalKey<T::with 19: rustc::ty::context::TyCtxt::createandenter 20: rustcdriver::driver::compileinput 21: rustcdriver::runcompilerwithpool 22: syntax::withglobals 23: <std::panic::AssertUnwindSafe<Fas core::ops::function::FnOnce<()::callonce 24: rustmaybecatchpanic at 25: rustcdriver::run 26: rustcdriver::main 27: std::rt::langstart::{{closure}} 28: std::panicking::try::docall at at 29: rustmaybecatchpanic at 30: std::rt::langstartinternal at at at 31: main 32: _libcstartmain 33: <unknownquery stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.28.0-nightly ( 2018-05-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type dylib
This does not happen on either stable or beta, only nightly.
if it's easy for you, any chance you could bisect with this tool? That would help us pinpoint precisely what introduced the fault. But this is presumably a simple fix...
Sorry, i was a little bit too sloppy. On stable it does not crash, but just because stable does not know the target thumv7em-none-eabi. Beta does indeed crash as well on the same error. I think will fix the problem, let's see. Hadn't time to do a bisect yet
Oh... this might be a new bug entiretly then. Most likely a bisection would point to the PR that said targets
I can confirm, that your patch fixes the ICE :) thanks . The question is, what is it supposed to do now. I creates a file, but it remains mostly empty (so no assembly is generated for that function). Is that what it is supposed to do?
I have no idea. Is that problematic?
Not at all, I'm just curious to know.

Related discussion:
text: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: --crate-type dylib --target thumbv7em-none-eabihf // compile-pass // error-pattern: dropping unsupported crate type `dylib` for target `thumbv7em-none-eabihf` #![feature(no_core)] #![no_std] #![no_core] </ins>