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

Language items are entirely unsafe #10666

Closed
emberian opened this issue Nov 26, 2013 · 2 comments
Closed

Language items are entirely unsafe #10666

emberian opened this issue Nov 26, 2013 · 2 comments
Labels
E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@emberian
Copy link
Member

The compiler never checks that the language item it receives is of the correct type or signature. This leads to craziness like:

#[no_std];

#[main]
#[lang="start"]
fn start() { }
[2:21:07]/tmp> rustc foo.rs
task 'rustc' has overflowed its stack
zsh: illegal hardware instruction (core dumped) rustc foo.rs

or, more benignly:

#[no_std];

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

#[main]
fn main() { }

which just plain asserts:

rustc: /build/rust-git/src/rust/src/llvm/lib/IR/Instructions.cpp:276: void llvm::CallInst::init(llvm::Value*, llvm::ArrayRef<llvm::Value*>, const llvm::Twine&): Assertion `(Args.size() == FTy->getNumParams() || (FTy->isVarArg() && Args.size() > FTy->getNumParams())) && "Calling a function with bad signature!"' failed.

or, more crazily:

#[no_std];

#[lang="start"]
mod a { }

#[main]
fn main() { }

which "just" ICEs:

error: internal compiler error: node_id_to_type: no type for node `mod a (id=2)`
This message reflects a bug in the Rust compiler. 
We would appreciate a bug report: https://github.com/mozilla/rust/wiki/HOWTO-submit-a-Rust-bug-report
task 'rustc' failed at 'explicit failure', /build/rust-git/src/rust/src/libsyntax/diagnostic.rs:102
task '<main>' failed at 'explicit failure', /build/rust-git/src/rust/src/librustc/lib.rs:395

Language items are the interface between the compiler and the language. They need to be well-defined and verified for correctness.

@huonw
Copy link
Member

huonw commented Nov 26, 2013

Possibly a dup of #9307.

@alexcrichton
Copy link
Member

Closing in favor of #9307 as that's probably the best solution to go about doing this (although these are some good test cases).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

No branches or pull requests

3 participants