Fix ICE in `let_unit_value` when calling a static or const callable type
fixes#8821
changelog: Fix ICE in `let_unit_value` when calling a static or const callable type
rustdoc: Remove doc link resolution fallback to all `macro_rules` in the crate
This is a deny-by-default lint detecting such fallback for crater run, as discussed in https://github.com/rust-lang/rust/pull/96521.
Remove potentially misleading realloc parenthetical
This parenthetical is problematic, because it suggests that the following is sound:
```rust
let layout = Layout:🆕:<[u8; 32]>();
let p1 = alloc(layout);
let p2 = realloc(p1, layout, 32);
if p1 == p2 {
p1.write([0; 32]);
dealloc(p1, layout);
} else {
dealloc(p2, layout);
}
```
At the very least, this isn't the case for [ANSI `realloc`](https://en.cppreference.com/w/c/memory/realloc)
> The original pointer `ptr` is invalidated and any access to it is undefined behavior (even if reallocation was in-place).
and [Windows `HeapReAlloc`](https://docs.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heaprealloc) is unclear at best (`HEAP_REALLOC_IN_PLACE_ONLY`'s description may imply that the old pointer may be used if `HEAP_REALLOC_IN_PLACE_ONLY` is provided).
The conservative position is to just remove the parenthetical.
cc `@rust-lang/wg-unsafe-code-guidelines` `@rust-lang/wg-allocators`
`undocumented_unsafe_blocks` does not trigger on unsafe trait impls
Closes#8505
changelog: This lint checks unsafe impls NOT from macro expansions and checks ones in macro declarations.
~~`unsafe impl`s from macro invocations don't trigger the lint for now.~~
~~This lint checks unsafe impls from/not from macro expansions~~
Rename `eq_ignore_case` to `starts_with_ignore_case`
The method doesn't test for equality. It tests if the object starts with
a given byte array, so its name is confusing.
Don't lint `vec_init_then_push` when further extended
fixes#7071
This will still lint when a larger number of pushes are done (four currently). The exact number could be debated, but this is more readable then a sequence of pushes so it shouldn't be too large.
changelog: Don't lint `vec_init_then_push` when further extended.
changelog: Remove `mut` binding from `vec_init_then_push` when possible.
Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery
As per the [reference](https://doc.rust-lang.org/1.51.0/reference/expressions.html#evaluation-order-of-operands) evaluation order is now defined.
I'm pretty sure rust always compiled with this evaluation order anyways so there's no reason the put an msrv limit on the lint.
changelog: Rename `eval_order_dependence` to `mixed_read_write_expression`, move to nursery
Sync rustc_codegen_cranelift
Since the last sync there have mostly been fixes of various sorts. I also changed cg_clif from using a custom driver to `-Zcodegen-backend` when built as separate project. When built as part of rust it was already using `-Zcodegen-backend`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Fix use of SetHandleInformation on UWP
The use of `SetHandleInformation` (introduced in #96441 to make `HANDLE` inheritable) breaks UWP builds because it is not available for UWP targets.
Proposed workaround: duplicate the `HANDLE` with `inherit = true` and immediately close the old one. Traditional Windows Desktop programs are not affected.
cc `@ChrisDenton`
Add rustc_nonnull_optimization_guaranteed to Owned/Borrowed Fd/Socket
PR #94586 added support for using
`rustc_nonnull_optimization_guaranteed` on values where the "null" value
is the all-ones bitpattern.
Now that #94586 has made it to the stage0 compiler, add
`rustc_nonnull_optimization_guaranteed` to `OwnedFd`, `BorrowedFd`,
`OwnedSocket`, and `BorrowedSocket`, since these types all exclude
all-ones bitpatterns.
This allows `Option<OwnedFd>`, `Option<BorrowedFd>`, `Option<OwnedSocket>`,
and `Option<BorrowedSocket>` to be used in FFI declarations, as described
in the [I/O safety RFC].
[I/O safety RFC]: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-safety.md#ownedfd-and-borrowedfdfd-1
rustc: Stricter checking for #[link] attributes
A subset of https://github.com/rust-lang/rust/pull/94962 that doesn't touch library renaming/reordering/deduplication.
`#[link]` attributes are checked for all kinds of unexpected arguments inside them.
I also tried to make wording for these errors more consistent, that's why some existing errors are changed, including errors for command line `-l` options.
Spans are also made more precise where possible.
Fix `download-ci-llvm` NixOS patching for `.so`s.
See https://github.com/rust-lang/rust/pull/95170#discussion_r872960686 - in short, `Path::ends_with` doesn't do the same thing as `str::ends_with`, and can only be used to check for whole file names, not extensions.
With this PR, I get the full suite of:
```
extracting /home/eddy/Projects/rust-A/build/cache/llvm-ebb80ec4e90f8622440f3e33562db0d6e6c66555-true/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.xz to /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm
info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/llvm-config
/nix/store/r4bzq2xilvv8fmqjg626hzwi22ah3hf4-rust-stage0-dependencies
info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck
info: you seem to be using Nix. Attempting to patch /home/eddy/Projects/rust-A/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so
```
(that `libLLVM-14-rust-1.62.0-nightly.so` at the end having been missing before)
r? `@Mark-Simulacrum` cc `@jyn514`
