This updates the `openssl-sys` crate to 0.9.87 to support building the
toolchain against the system libraries provided by LibreSSL version 3.7.x.
LibreSSL 3.7.x has been supported since `openssl-sys` version 0.9.85.
Because the literal pipe `|` character was not escaped, these regexes ended up
accidentally ignoring every line in the coverage report output, so the tests
would not fail even if the output was wrong.
Use MIR's `Offset` for pointer `add` too
~~Status: draft while waiting for #110822 to land, since this is built atop that.~~
~~r? `@ghost~~`
Canonical Rust code has mostly moved to `add`/`sub` on pointers, which take `usize`, instead of `offset` which takes `isize`. (And, relatedly, when `sub_ptr` was added it turned out it replaced every single in-tree use of `offset_from`, because `usize` is just so much more useful than `isize` in Rust.)
Unfortunately, `intrinsics::offset` could only accept `*const` and `isize`, so there's a *huge* amount of type conversions back and forth being done. They're identity conversions in the backend, but still end up producing quite a lot of unhelpful MIR.
This PR changes `intrinsics::offset` to accept `*const` *and* `*mut` along with `isize` *and* `usize`. Conveniently, the backends and CTFE already handle this, since MIR's `BinOp::Offset` [already supports all four combinations](adaac6b166/compiler/rustc_const_eval/src/transform/validate.rs (L523-L528)).
To demonstrate the difference, I added some `mir-opt/pre-codegen/` tests around slice indexing. Here's the difference to `[T]::get_mut`, since it uses `<*mut _>::add` internally:
```diff
`@@` -79,30 +70,21 `@@` fn slice_get_mut_usize(_1: &mut [u32], _2: usize) -> Option<&mut u32> {
StorageLive(_12); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL
StorageLive(_9); // scope 6 at $SRC_DIR/core/src/slice/index.rs:LL:COL
_9 = _8 as *mut u32 (PtrToPtr); // scope 11 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageLive(_13); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _13 = _2 as isize (IntToInt); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageLive(_14); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageLive(_15); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _15 = _9 as *const u32 (Pointer(MutToConstPointer)); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _14 = Offset(move _15, _13); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageDead(_15); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _7 = move _14 as *mut u32 (PtrToPtr); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageDead(_14); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageDead(_13); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
+ _7 = Offset(_9, _2); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
StorageDead(_9); // scope 6 at $SRC_DIR/core/src/slice/index.rs:LL:COL
StorageDead(_12); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL
StorageDead(_11); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL
```
1c1c8e442a (diff-a841b6a4538657add3f39bc895744331453d0625e7aace128b1f604f0b63c8fdR80)
I was curious about how many `Encodable`/`Decodable` derives we have.
Some grepping revealed that it's over 500 of each, but the number of
`Encodable` ones was higher, which was weird. Most of the
`Encodable`-only ones were in `hir.rs`. This commit removes them all,
plus some other unnecessary derives in that file and others that I found
via trial and error.
Checking that `read_raw_bytes(len)` changes the position by `len` is a
reasonable thing for a test, but isn't much use in just one of the
zillion `Decodable` impls.
I happened to notice one of these not getting inlined as part of `Range::next` in <https://rust.godbolt.org/z/4WKWWxj1G>
```rust
bb1: {
StorageLive(_5);
_6 = &mut _4;
StorageLive(_21);
StorageLive(_14);
StorageLive(_15);
_15 = &((*_6).0: usize);
StorageLive(_16);
_16 = &((*_6).1: usize);
_14 = <usize as PartialOrd>::lt(move _15, move _16) -> bb7;
}
```
So since a call for something this trivial is never the right choice, `#[inline(always)]` seems appropriate.
`remove_dir_all`: try deleting the directory even if `FILE_LIST_DIRECTORY` access is denied
If opening a directory with `FILE_LIST_DIRECTORY` access fails then we should try opening without requesting that access. We may still be able to delete it if it's empty or a link.
Fixes https://github.com/rust-lang/cargo/issues/12042
Add some missing built-in lints
(and also sort them, so this is best reviewed one commit at a time)
Fixes#110911
I wonder if there's a good way to detect when a lint is built-in (i.e. not associated to a lint pass). If so, it needs to be added to this list, or else we're unable to `allow` or `deny` it. Leaving that for future work, I guess...
Migrate trivially translatable `rustc_parse` diagnostics
cc #100717
Migrate diagnostics in `rustc_parse` which are emitted in a single statement. I worked on this by expanding the lint introduced in #108760, although that isn't included here as there is much more work to be done to satisfy it
More core::fmt::rt cleanup.
- Removes the `V1` suffix from the `Argument` and `Flag` types.
- Moves more of the format_args lang items into the `core::fmt::rt` module. (The only remaining lang item in `core::fmt` is `Arguments` itself, which is a public type.)
Part of https://github.com/rust-lang/rust/issues/99012
Follow-up to https://github.com/rust-lang/rust/pull/110616
Document `const {}` syntax for `std::thread_local`.
It exists and is pretty cool. More people should use it.
It was added in #83416 and stabilized in #91355 with the tracking issue #84223.
If opening a directory with `FILE_LIST_DIRECTORY` access fails then we should try opening without requesting that access. We may still be able to delete it if it's empty or a link.
Change memory ordering in System wrapper example
Currently, the `SeqCst` ordering is used, which seems unnecessary:
+ Even `Relaxed` ordering guarantees that all updates are atomic and are executed in total order
+ User code only reads atomic for monitoring purposes, no "happens-before" relationships with actual allocations and deallocations are needed for this
If argumentation above is correct, I propose changing ordering to `Relaxed` to clarify that no synchronization is required here, and improve performance (if somebody copy-pastes this example into their code).
Correct `std::prelude` comment
(Read the changed file first for context.)
First, `alloc` has no prelude.
Second, the docs for `v1` don't matter since the [prelude module] already has all the doc links. The `rust_2021` module for instance also doesnt have a convenient doc page. However as I understand glob imports still cant be used because the items dont have the same stabilisation versions.
[prelude module]: https://doc.rust-lang.org/std/prelude/index.html
docs(std): clarify remove_dir_all errors
When using `remove_dir_all`, I assumed that the function was idempotent and that I could always call it to remove a directory if it existed. That's not the case and it bit me in production, so I figured I'd submit this to clarify the docs.
Fixes https://github.com/rust-lang/rust/issues/110912
Checking `flavor == RlibFlavor::Normal` was accidentally lost in
601fc8b36bhttps://github.com/rust-lang/rust/pull/105601
That caused combining +whole-archive and +bundle link modifiers on
non-rlib crates to fail with a confusing error message saying that
combination is unstable for rlibs. In particular, this caused the
build to fail when +whole-archive was used on staticlib crates, even
though +whole-archive effectively does nothing on non-bin crates because
the final linker invocation is left to an external build system.
