Otherwise, we can get into a situation where you have
a subtype obligation `#1 <: #2` pending, #1 is constrained
by `check_casts`, but #2` is unaffected.
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
Do not mark `-Z thir-unsafeck` as unsound anymore
The initial implementation of the THIR unsafety checker is now complete (rust-lang/project-thir-unsafeck#7).
r? `@oli-obk`
Add notes to macro-not-found diagnostics to point out how things with the same name were not a match.
This adds notes like:
```
error: cannot find derive macro `Serialize` in this scope
--> $DIR/issue-88206.rs:22:10
|
LL | #[derive(Serialize)]
| ^^^^^^^^^
|
note: `Serialize` is imported here, but it is not a derive macro
--> $DIR/issue-88206.rs:17:11
|
LL | use hey::{Serialize, Deserialize};
| ^^^^^^^^^
```
Fixes https://github.com/rust-lang/rust/issues/88206
Includes https://github.com/rust-lang/rust/pull/88229
r? `@estebank`
2229: Handle MutBorrow/UniqueImmBorrow better
We only want to use UniqueImmBorrow when the capture place is truncated and we
drop Deref of a MutRef.
r? `@nikomatsakis`
Fixes: https://github.com/rust-lang/project-rfc-2229/issues/56
Implement `AsFd` etc. for `UnixListener`.
Implement `AsFd`, `From<OwnedFd>`, and `Into<OwnedFd>` for
`UnixListener`. This is a follow-up to #87329.
r? `@joshtriplett`
Previously, converting `&mut [T; N]` to `&[Cell<T>; N]` looks like this:
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(&mut array[..])
.as_slice_of_cells()
.try_into()
.unwrap();
With this new helper method, it looks like this:
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(array).as_array_of_cells();
Stop emitting the `dso_local` LLVM attribute for external symbols under the static relocation model on macOS.
This matches Clang's behavior:
973cb2c326/clang/lib/CodeGen/CodeGenModule.cpp (L1038-L1040)
Even if `dso_local` were properly supported in this way on macOS, it seems
incorrect to add this annotation as liberally as we did. The `dso_local`
annotation is for symbols that ultimately end up in the same linkage unit, but
we were adding this annotation even for `static` values inside `extern` blocks
marked with `#[link(type="framework")]`, which should be considered dynamically
linked. Note that Clang likewise avoids emitting `dso_local` for `dllimport`
symbols:
973cb2c326/clang/lib/CodeGen/CodeGenModule.cpp (L1005-L1007)
This issue caused breakage in the `ring` crate, which links to a symbol defined
in `Security.framework` that ultimately resolves to address `0x0`:
b94d61e044/src/rand.rs (L390)
For this symbol, the use of `dso_local` causes LLVM to emit a relocation of
type `X86_64_RELOC_SIGNED`, which is a 32-bit signed PC-relative offset. If the
binary is large enough, `0x0` might be out of range, and the link will fail.
Avoiding `dso_local` causes LLVM to use the GOT instead, emitting a relocation
of type `X86_64_RELOC_GOT_LOAD`, which will properly handle the large offset
and cause the link to succeed.
As a side note, the static relocation model is effectively deprecated for
security reasons on macOS, as it prohibits PIE. It's also completely
unsupported on Apple Silicon, so I don't think it's worth going to the effort
of properly supporting this model on that platform.
