Fix performance regression in debuginfo file_metadata.
Fixes performance regression caused by #69718.
Finding the `SourceFile` associated with a `FileName` called `get_source_file` on the `SourceMap`, which does a linear search through all files in the `SourceMap`.
This resolves the issue by passing the `SourceFile` in from the caller (which already had it available) instead of the `FileName`
Fixes#70785.
Finding the `SourceFile` associated with a `FileName` called `get_source_file` on
the `SourceMap`, which does a linear search through all files in the `SourceMap`.
This resolves the issue by passing the SourceFile in from the caller (which already
had it available).
Rollup of 6 pull requests
Successful merges:
- #70635 (rustc_target: Some cleanup to `no_default_libraries`)
- #70748 (Do not disable field reordering on enums with big discriminant)
- #70752 (Add slice::fill)
- #70766 (use ManuallyDrop instead of forget inside collections)
- #70768 (macro_rules: `NtLifetime` cannot start with an identifier)
- #70783 (comment refers to removed type)
Failed merges:
r? @ghost
use ManuallyDrop instead of forget inside collections
This PR changes some usage of `mem::forget` into `mem::ManuallyDrop` in some `Vec`, `VecDeque`, `BTreeMap` and `Box` methods.
Before the commit, the generated IR for some of the methods was longer, and even after optimization, some unwinding artifacts were still present.
Add slice::fill
Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function.
## Usage
```rust
let mut buf = vec![0; 10];
buf.fill(1);
assert_eq!(buf, vec![1; 10]);
```
## Performance
When compiling in release mode, for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile.
## Why now?
Conversations about adding `slice::fill` are not new. In fact, https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details, and it's not seen much forward motion since.
In ["The Hunt for the Fastest Zero"](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc, comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests, the author notes the following:
> That the optimization fails, perhaps unexpectedly, in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms, at least where performance matters, for example by replacing std::fill with memset? I don’t think so.
Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values, so it either needs to be optimized at the MIR layer, or more likely rely on LLVM's optimizer.
By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec<u8>` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that, it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples.
## References
- [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/)
- [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html)
- [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067)
- [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill)
- [ASM output on Godbolt](https://godbolt.org/z/5-XU66)
Do not disable field reordering on enums with big discriminant
The field are always re-ordered to minimize padding, regardless of the
alignment of the discriminant
(spinoff from #70477)
update openssl-src to 111.8.1+1.1.1f
This update includes a fix for alexcrichton/openssl-src-rs#52 which allows Cargo to build correctly on Solaris/illumos.
This commit changes some usage of mem::forget into mem::ManuallyDrop
in some Vec, VecDeque, BTreeMap and Box methods.
Before the commit, the generated IR for some of the methods was
longer, and even after optimization, some unwinding artifacts were
still present.
typeck/type_of: let wfcheck handle generics in opaque types' substs.
I was working on #70164, and `type_of`'s handling of opaque types seemed to be, by far, the trickiest use of `Ty::walk`, but I believe it wasn't doing anything (see https://github.com/rust-lang/rust/pull/57896#discussion_r396064431 - I suspect, based on glancing at the PR discussion, that an early attempt was kept in, despite becoming just an overcomplicated way to do exactly the same as the previous simple type equality check).
I would've loved to remove `ResolvedOpaqueTy` (keep the `Ty` and lose the `Substs`), but it looks like the MIR borrowck part of the process needs that now, so it would've been added anyway since #57896, even if that PR hadn't happened.
<hr/>
In the process, I've moved the remaining substitution validation to `wfcheck`, which was already handling lifetimes, and kept only `delay_span_bug`s in `type_of`, as an insurance policy.
I've added tests for lifetime and const cases, they seem to be checked correctly now.
(and more uniform than they were in https://github.com/rust-lang/rust/issues/63063#issuecomment-602162804)
However, the quality of the errors is maybe a bit worse, and they don't trigger when there are other errors (not sure if this is due to compilation stop points or something more specific to one opaque type).
r? @nikomatsakis cc @matthewjasper @oli-obk @Aaron1011
add basic IP support in HermitCore
- add initial version to support sockets
- use TcpStream as test case
- HermitCore uses smoltcp as IP stack for pure Rust applications
- further functionalities (e.g. UDP support) will be added step by step
- in principle, the current PR is a revision of #69404
Add hash of source files in debug info
LLVM supports placing the hash of source files inside the debug info.
This information can be used by a debugger to verify that the source code matches
the executable.
This change adds support for both hash algorithms supported by LLVM, MD5 and SHA1, controlled by a target option.
* DWARF only supports MD5
* LLVM IR supports MD5 and SHA1 (and SHA256 in LLVM 11).
* CodeView (.PDB) supports MD5, SHA1, and SHA256.
Fixes#68980.
Tracking issue: #70401
rustc dev guide PR with further details: https://github.com/rust-lang/rustc-dev-guide/pull/623
