`assert_eq!` has better diagnostics than `assert!` and is more helpful when something actually breaks, but the diagnostics has it's price - `assert_eq!` generate some formatting code which is slower to compile and possibly run.
[My measurements](https://internals.rust-lang.org/t/assert-a-b-or-assert-eq-a-b/1367/12?u=petrochenkov) show that presence of this formatting code doesn't affect compilation + execution time of the test suite significantly, so `assert_eq!` can be used instead of `assert!` consistently.
(Some tests doesn't reside in src/test, they are not affected by these changes, I'll probably open a separate PR for them later)
This test has an interesting history, because of fail -> panic. It was
originally called extern-fail.rs:
https://github.com/rust-lang/rust/commits/master/src/test/run-fail/extern-fail.rs
It lived for a while, but was disabled in August 2013:
ce95b01014
As you can see, that failure was not specific to this test, however,
this code does stuff with the runtime, which was removed. Given that
it hasn't even been able to compile in a long time, we should just
remove it.
r? @brson
Two commits here: one which removes a bunch of tests, and re-enables a few that work.
Second updates the syntax of one of the failing tests. It still doesn't pass, but at least it compiles.
Most of these are old, but some specific messages for specific tests:
* trait-contravariant-self.rs: failed due to a soundess hole:
05e3248a79
* process-detatch: 15966c3c1f
says "this test is being ignored until signals are implemented" That's
not happening for a long time, and when it is, we'll write tests for
it.
* deep-vector{,2}.rs: "too big for our poor macro infrastructure", and has
been ignored over a year.
* borrowck-nested-calls.rs's FIXME #6268 was closed in favor of
rust-lang/rfcs#811
* issue-15167.rs works properly now
* issue-9737.rs works properly now
* match-var-hygiene.rs works properly now
Addresses a chunk of #3965
This test has an interesting history, because of fail -> panic. It was
originally called extern-fail.rs:
https://github.com/rust-lang/rust/commits/master/src/test/run-fail/extern-fail.rs
It lived for a while, but was disabled in August 2013:
ce95b01014
As you can see, that failure was not specific to this test, however,
this code does stuff with the runtime, which was removed. Given that
it hasn't even been able to compile in a long time, we should just
remove it.
`driver::build_output_filenames` calls `file_stem` on a PathBuf obtained from the output file compiler flag. It's possible to pass the empty string to this compiler flag. When file_stem is called on an empty Path, it returns None, which is unwrapped and the compiler panics.
This change modifies the `unwrap` to an `unwrap_or` so that the empty string is passed through the compilation pipeline until it reaches `trans:🔙:write_output_file`, which will emit an appropriate error.
Instead of panicking, the error that is emitted now is:
```
$ rustc -o "" thing.rs
error: could not write output to : No such file or directory
```
The `:` is a little strange, but it /is/ reporting the filename (the empty string) correctly, I suppose. Both gcc and clang hand the output file to ld, which emits a similar error message when faced with the empty string as an output file:
```
$ clang -o "" thing.c
ld: can't open output file for writing: , errno=2 for architecture x86_64
```
This PR also adds a test for this, in `run-make`. This fixes issue #26092.
* Removes `RustJITMemoryManager` from public API.
This was really sort of an implementation detail to begin with.
* `__morestack` is linked to C++ wrapper code and this pointer
is used when resolving the symbol for `ExecutionEngine` code.
* `__morestack_addr` is also resolved for `ExecutionEngine` code.
This function is sometimes referenced in LLVM-generated code,
but was not able to be resolved on Mac OS systems.
* Added Windows support to `ExecutionEngine` API.
* Added a test for basic `ExecutionEngine` functionality.
* Removes `RustJITMemoryManager` from public API.
This was really sort of an implementation detail to begin with.
* `__morestack` is linked to C++ wrapper code and this pointer
is used when resolving the symbol for `ExecutionEngine` code.
* `__morestack_addr` is also resolved for `ExecutionEngine` code.
This function is sometimes referenced in LLVM-generated code,
but was not able to be resolved on Mac OS systems.
* Added Windows support to `ExecutionEngine` API.
* Added a test for basic `ExecutionEngine` functionality.
With the latter is provided by the `From` conversion trait, the former is now completely redundant. Their code is identical. Let’s deprecate now and plan to remove in the next cycle. (It’s `#[unstable]`.)
r? @alexcrichton
CC @nagisa
