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)
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
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!
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.
Rust's current compilation model makes it impossible on Windows to generate one
object file with a complete and final set of dllexport annotations. This is
because when an object is generated the compiler doesn't actually know if it
will later be included in a dynamic library or not. The compiler works around
this today by flagging *everything* as dllexport, but this has the drawback of
exposing too much.
Thankfully there are alternate methods of specifying the exported surface area
of a dll on Windows, one of which is passing a `*.def` file to the linker which
lists all public symbols of the dynamic library. This commit removes all
locations that add `dllexport` to LLVM variables and instead dynamically
generates a `*.def` file which is passed to the linker. This file will include
all the public symbols of the current object file as well as all upstream
libraries, and the crucial aspect is that it's only used when generating a
dynamic library. When generating an executable this file isn't generated, so all
the symbols aren't exported from an executable.
To ensure that statically included native libraries are reexported correctly,
the previously added support for the `#[linked_from]` attribute is used to
determine the set of FFI symbols that are exported from a dynamic library, and
this is required to get the compiler to link correctly.
