I was not able to come up with tests that would expose this bug, as, apparently, Rust types of the args are not used for anything but debug logging.
Thanks to @luqmana for pointing this out!
LLVM might perform tail merging on the calls that initiate the unwinding
process which breaks debuginfo and therefore this test. Since tail
merging is guaranteed to break debuginfo, it should be disabled for this
test.
This allows us to restore a testcase that I had to remove earlier
because of the same problem, because back then I didn't realize that
disabling tail merging was an option.
cc #27619
As title :-)
Part of #24407.
r? @Manishearth
This will need merging with E0193, so probably want to delay any r+ until that goes in and I can merge myself.
See line 181: The lookup should start with the random index and iterate from there.
Also locked stdout (which makes it a bit faster on my machine). And the `make_lookup` function now uses `map` (as the TODO asked for).
Perhaps the multi-thread output from the fasta benchmark could be used to speed it up even more.
This commit leverages the runtime support for DWARF exception info added
in #27210 to enable unwinding by default on 64-bit MSVC. This also additionally
adds a few minor fixes here and there in the test harness and such to get
`make check` entirely passing on 64-bit MSVC:
* The invocation of `maketest.py` now works with spaces/quotes in CC
* debuginfo tests are disabled on MSVC
* A link error for librustc was hacked around (see #27438)
Because I wanted to change the pretty test as little as possible I added `// compiler-flags: --crate-type=lib` to those test that failed because of a missing `main`. Passes `make check-stage1-pretty` locally.
cc @nrc
cc #27567
I have no idea how bors keeps working without this - I can only assume it's some peculiarity of how windows searches for DLLs.
Without this change, running `make check` on windows will not correctly set PATH to include eg. `x86_64-pc-windows-gnu\stage1\bin\rustlib\x86_64-pc-windows-gnu\lib`, and when it tries to run eg. `stage1/test/stdtest-x86_64-pc-windows-gnu.exe`, it will fail because windows can't find the DLLs on which it relies.
It seems to be just a mistake: when the equivalent was added for the branch that deals with unix-like platforms, the windows branch was left unchanged.
The "nth" element can be confusing. In an array context, we know indexes
start from 0 but one may believe this is not the case with "nth". For
example, would `.nth(1)` return the first (1th/1st) or the second
element? Rephrase a bit to be less confusing.
r? @steveklabnik
The previous wording was confusing. While would we need to go through
the whole list just to find the first code point? `chars()` being an
iterator, we only need to walk from the beginning of the list.
Note that I am not a native English speaker and I have still difficulties to spot if a "the" is needed somewhere. Feel free to take this PR as a mere suggestion.
r? @steveklabnik
`FormatMessageW` always inserts trailing `\r\n` to system messages which is a minor annoyance when they're fed to `Debug` but can break formatting with `Display`.
```rust
fn main() {
use std::env;
if let Err(err) = env::set_current_dir("???") {
println!("{:#?}\n{}", err, err);
}
}
```
```_
Error {
repr: Os {
code: 2,
message: "The system cannot find the file specified.\r\n"
}
}
The system cannot find the file specified.
(os error 2)
```
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
