Change:
<ins> // aux-build:issue-49544.rs // check-pass extern crate issue_49544; use issue_49544::foo; fn main() { let _ = foo(); } </ins>

Discussion:
Expressions involving an adaptor function like can cause an internal compiler error. If a line of code in a submodule uses an undeclared type or module in an expression using an adaptor, the compiler panics at . Code in a submodule needs to specify a path relative to the crate root, which means prefixing to a call like . We will use the following two files to demonstrate the issue: Code in a submodule needs to specify a path relative to the crate root, which means prefixing to a call like . If we use the program compiles and runs successfully. As written however, the files above cause this internal compiler error: This panic will occur for other adapters, like . After commenting out the line, the compiler does not panic. and only this output is seen after trying to compile: I ran into this error because the error is not required for code in the crate root. If is moved from to , then the internal compiler error no longer occurs. If code outside of the crate root causes an error due to the use of an undeclared type or module, it would be nice if the compiler warning would mention the possibility of a missing prefix, if the name that could not be resolved was a type or module in the standard library. When I reviewed the information given by running , it mostly mentions the possibility of typos being the cause of this error. Mentioning some other common situations that lead to symbols failing to resolve might be helpful. : Backtrace: P.S. I am still somewhat new to Rust, but I would love to help out with this however I can!
I just tested it and it doesn't ICE anymore, at least not on nightly.

Unexpected non-scalars in register inputs of can ICE the compiler. To reproduce: This mistake goes uncaught until it reaches where it s. I would expect it to have been caught earlier, during argument validation. I've found a similar case which dumps core, which will be the subject of a separate bug. : rustc 1.14.0-nightly ( 2016-10-26) binary: rustc commit-hash: commit-date: 2016-10-26 host: x8664-unknown-linux-gnu release: 1.14.0-nightly LLVM version: 3.9 Backtrace:
Got an updated backtrace:
Ran into this with which I would sort of hope would just work. Backtrace is identical (at least as far as a compiler without debugging information outputs).
Still reproducible with .
No longer reproduces:

Program: Crate test1lib: Notice that this is a static in one crate referencing a static in another crate. A complete cargo-buildable test case is at This bug was found by a user of . The coding pattern in this test case commonly occurs when using ring. To reproduce: rustc crashes with Reproduced with (on x86_64-pc-windows-msvc): rustc 1.3.0 ( 2015-09-15) / cargo 0.4.0-nightly ( 2015-08-03) (built 2015-08-03) rustc 1.4.0-nightly ( 2015-08-27) / cargo 0.5.0-nightly ( 2015-08-26) rustc 1.5.0-nightly ( 2015-10-22) / cargo 0.6.0-nightly ( 2015-10-22)
In particular, this was found by who originally reported it as
Triaging: There is an error hapening on , but it is not the Assertion on GEP indices anymore. On nightly the example compiles without errors.
Stable probably still hits the same assert, but LLVM assertions are disabled on stable and beta
This no longer asserts on the current nightly.