Clean up handling of `-Z pgo-gen` commandline option.
This PR adapts the `-Z pgo-gen` flag to how Clang and GCC handle the corresponding `-fprofile-generate` flag. In particular, the flag now optionally takes a directory to place the profiling data in and allows to omit the argument (instead of having to pass an empty string).
Exclude profiler-generated symbols from MSVC __imp_-symbol workaround.
LLVM's profiling instrumentation adds a few symbols that are used by the profiler runtime. Since these show up as globals in the LLVM IR, the compiler generates `dllimport`-related `__imp_` stubs for them. This can lead to linker errors because the instrumentation symbols have weak linkage or are in a comdat section, but the `__imp_` stubs aren't.
Instead of trying to replicate the linkage/comdat setup for the stubs, this PR just excludes the profiler-related symbols from stub-generation since they aren't supposed to be referenced via `__declspec(dllimport)` anywhere anyway.
r? @alexcrichton
EDIT: I considered making this more general, i.e. inferring from the symbol name if it is a Rust symbol or not. But then I figured out that that would yield false negatives for `#[no_mangle]` et al, so I went with a blacklist approach.
Exclude some copies of old book editions from search engines
These are only stubs that confuse search engine users. There's no useful content in these locations.
std: Add `{read,write}_vectored` for more types
This commit implements the `{read,write}_vectored` methods on more types
in the standard library, namely:
* `std::fs::File`
* `std::process::ChildStd{in,out,err}`
* `std::io::Std{in,out,err}`
* `std::io::Std{in,out,err}Lock`
* `std::io::Std{in,out,err}Raw`
Where supported the OS implementations hook up to native support,
otherwise it falls back to the already-defaulted implementation.
Use normal newtype_index macro for MIR dataflows
* Makes the definition of these structs contain `struct IndexName`
* Avoids having an offset by removing high values, rather than 0
* Implements some traits for us.
Use measureme in self profiler
r? @michaelwoerister
~Changes are still very rough.~
~I'm not sure what the right way to add the `measureme` dependency is. Currently it's just added with a relative path which Works On My Machine ™️.~
I'm also not sure what to do with the category data.
Rollup of 8 pull requests
Successful merges:
- #59781 (Remove check_match from const_eval)
- #59820 (proc_macro: stop using LEB128 for RPC.)
- #59846 (clarify what the item is in "not a module" error)
- #59847 (Error when using `catch` after `try`)
- #59859 (Suggest removing `?` to resolve type errors.)
- #59862 (Tweak unstable diagnostic output)
- #59866 (Recover from missing semicolon based on the found token)
- #59892 (Impl RawFd conversion traits for WASI TcpListener, TcpStream and UdpSocket)
Failed merges:
r? @ghost
Recover from missing semicolon based on the found token
When encountering one of a few keywords when a semicolon was
expected, suggest the semicolon and recover:
```
error: expected one of `.`, `;`, `?`, or an operator, found `let`
--> $DIR/recover-missing-semi.rs:4:5
|
LL | let _: usize = ()
| - help: missing semicolon here
LL |
LL | let _ = 3;
| ^^^
error[E0308]: mismatched types
--> $DIR/recover-missing-semi.rs:2:20
|
LL | let _: usize = ()
| ^^ expected usize, found ()
|
= note: expected type `usize`
found type `()`
```
clarify what the item is in "not a module" error
The motivation here was that I was trying to import an associated constant when I thought it was an enum variant, and got confused by this error.
Ideally I would like to add a note saying that associated constants, types, and methods cannot be imported, but I'm not sure that the associated items for a `Def` can be checked at resolve time.
Remove check_match from const_eval
This fixes#59378.
It seems that the `check_match` may be unnecessary, so this removes it per instructions provided in the issue. I re-ran the tests for `librustc_mir` and everything seemed fine!
Add discr_index to multi-variant layouts
We remove the assumption that the discriminant is always field 0, in
preparations for layouts like generators where this is not (always) going to be
the case.
Specifically, upvars are going to go before the discriminant. In theory, it's possible to remove _that_ assumption instead and keep the discriminant at field index 0, but one assumption or the other had to go :)
There is one place I know of in the debuginfo code where we'll still need to remove assumptions that the discriminant is the _only_ field. I was planning on doing this along with the upcoming generator change, which will also include tests that exercise the code changing in this PR.
r? @eddyb
cc @oli-obk
cc @cramertj
