Conversation
|
A simple run-pass test making use of it would be nice, even though it can't be directly tested. |
|
What happens in a program like this? use std::intrinsics;
fn main() {
unsafe { intrinsics::unreachable(); }
} |
|
That has undefined behaviour, it's the point of the intrinsic. It's the same thing as |
|
My use case is something like pub fn exit(n: uint) -> ! {
static NR_EXIT: uint = 60;
unsafe {
asm!("syscall"
:: "{rax}"(NR_EXIT), "{rdi}"(n));
intrinsics::unreachable()
}
}which compiles on x86-64 Linux to just Without the intrinsic I need something like |
|
Not sure why the Travis build failed. The log shows |
|
Travis always fails its llvm 3.4 build atm. The 3.3 one succeeded though, which is the important one. |
|
Does this avoid crashing horribly? (iirc there have been crashes due to LLVM assertions about unreachability previously) fn foo() {
unreachable();
println!("foo");
} |
|
It doesn't crash rustc, no. |
|
@huonw, @thestinger: Any more thoughts about this? |
|
Any way I can get the contents of |
|
Not at this point sadly, the bots clean out all previous runs when they make a new build. You could update the test, however, to print it out and we can push to try. |
|
@kmcallister: Please note that on Win64, the 'unreachable' instruction actually emits code. |
|
Aha! |
|
FWIW, matching an empty enum will produce an unreachable instruction: use std::any::Void;
use std::intrinsics::transmute;
fn main() {
let x: Void = unsafe { transmute(()) };
match x {}
}%"enum.core::any::Void<[]>[#3]" = type {}
; Function Attrs: uwtable
define internal void @_ZN4main20h31af98ebf3d86da3gaaE() unnamed_addr #0 {
entry-block:
%x = alloca %"enum.core::any::Void<[]>[#3]"
unreachableso the |
There was a problem hiding this comment.
I'm not sure whether tests should feature idiomatic code, but in this case I think it'd be better if you'd mark this function unsafe.
|
Rebased and addressed @tbu-'s comment. r? @thestinger |
I'm not sure how to add an automated test for this.
Fix tasks in tasks.json rust-lang#16839 refactored the representation of tasks inside the VS Code extension. However, this data type is exposed to users, who can define their own tasks in the same format in `tasks.json` or `.code-workspace`. Revert the data type to have a `command` field rather than a `program` field, and document the different fields. This code is also a little complex, so split out a `cargoToExecution` to handle the Task to Execution conversion logic. After this change, any tasks.json with a `command` field works again. For example, the following tasks.json works as expected: ``` { "version": "2.0.0", "tasks": [ { "type": "cargo", "command": "build", "problemMatcher": [ "$rustc" ], "group": "build", "label": "my example cargo build task" } ] } ``` Fixes rust-lang#16943 rust-lang#16949
Fix tasks in tasks.json rust-lang#16839 refactored the representation of tasks inside the VS Code extension. However, this data type is exposed to users, who can define their own tasks in the same format in `tasks.json` or `.code-workspace`. Revert the data type to have a `command` field rather than a `program` field, and document the different fields. This code is also a little complex, so split out a `cargoToExecution` to handle the Task to Execution conversion logic. After this change, any tasks.json with a `command` field works again. For example, the following tasks.json works as expected: ``` { "version": "2.0.0", "tasks": [ { "type": "cargo", "command": "build", "problemMatcher": [ "$rustc" ], "group": "build", "label": "my example cargo build task" } ] } ``` Fixes rust-lang#16943 rust-lang#16949
I'm not sure how to add an automated test for this.