Fix CFI: f32 and f64 are encoded incorrectly for cross-language CFI
Fix#115150 by encoding f32 and f64 correctly for cross-language CFI. I missed changing the encoding for f32 and f64 when I introduced the integer normalization option in #105452 as integer normalization does not include floating point. `f32` and `f64` should be always encoded as `f` and `d` since they are both FFI safe when their representation are the same (i.e., IEEE 754) for both the Rust compiler and Clang.
Fix#115150 by encoding f32 and f64 correctly for cross-language CFI. I
missed changing the encoding for f32 and f64 when I introduced the
integer normalization option in #105452 as integer normalization does
not include floating point. `f32` and `f64` should be always encoded as
`f` and `d` since they are both FFI safe when their representation are
the same (i.e., IEEE 754) for both the Rust compiler and Clang.
Allow explicit `#[repr(Rust)]`
This is identical to no `repr()` at all. For `Rust, packed` and `Rust, align(x)`, it should be the same as no `Rust` at all (as, afaik, `#[repr(align(16))]` uses the Rust ABI.)
The main use case for this is being able to explicitly say "I want to use the Rust ABI" in very very rare circumstances where the first obvious choice would be the C ABI yet is undesirable, which is already possible with functions as `extern "Rust"`. This would be useful for silencing https://github.com/rust-lang/rust-clippy/pull/11253. It's also more consistent with `extern`.
The lack of this also tripped me up a bit when I was new to Rust, as I expected this to be possible.
Add symbols for Clippy usage
The `arithmetic_side_effects` lint is always "interning" these non-existing symbols related to math operations causing a bit of a slowdown.
Fix ub-int-array test for big-endian platforms
As of commit 7767cbb3b0, the tests/ui/consts/const-eval/ub-int-array.rs test is failing on big-endian platforms (in particular s390x), as the stderr output contains a hex dump that depends on endianness.
Since this point intentionally verifies the hex dump to check the uninitialized byte markers, I think we should not simply standardize away the hex dump as is done with some of the other tests in this directory.
However, most of the test is already endian-independent. The only exception is one line of hex dump, which can also be made endian-independent by choosing appropriate constants in the source code.
Since the 32bit and 64bit stderr outputs were already (and remain) identical, I've merged them and removed the stderr-per-bitwidth marker.
Fixes (again) https://github.com/rust-lang/rust/issues/105383.
Move some ui tests to subdirectories
cc #73494
issue-2804 -> `macros/` (there's already the minified `issue-2804-2` there)
issue-17431 -> `structs-enums/struct-rec` and new `structs-enums/enum-rec` (original issue pertains to detection of recursive enums and structs)
issue-29181 and issue-66768 - moved according to the classifier tool
refactor(lint): translate `RenamedOrRemovedLint`
I was trying to address <https://github.com/rust-lang/cargo/issues/12495> and found that maybe I should refactor relevant lints a bit.
This PR translates `RenamedOrRemovedLint` into fluent file. To make diagnostic types clearer and easier to organize, this PR splits it into two structs.
The second commit adds lifetime annotations for removing unnecessary clones. If people feel too noisy, we can revert such change.
### Possibly relevant UI tests:
* `tests/ui/lint-removed*`
* `tests/ui/lint-renamed*`
* `tests/ui/rustdoc-renamed.rs`
* `tests/rustdoc-ui/lints/unknown-renamed-lints.rs`
kmc-solid: Import `std::sync::PoisonError` in `std::sys::solid::os`
Follow-up to #114968. Fixes a missing import in [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
```
error[E0433]: failed to resolve: use of undeclared type `PoisonError`
C:\Users\xxxxx\.rustup\toolchains\nightly-2023-08-23-x86_64-pc-windows-gnu\lib\rustlib\src\rust\library\std\src\sys\solid\os.rs(85,36)
|
85 | ENV_LOCK.read().unwrap_or_else(PoisonError::into_inner)
| ^^^^^^^^^^^ use of undeclared type `PoisonError`
|
```
Detect and report nix shell
Better diagnostics for people using nix subshell on non-NixOS.
1. Turned patch-binaries-for-nix from a boolean into a ternary flag: true, false, and unset.
2. When patch-binaries-for-nix is unset, we continue with the existing NixOS detection heuristic (look for nixos in /etc/os-release, if present), but if we are not atop NixOS, then issue a note if we see the IN_NIX_SHELL environment variable telling the user to consider setting patch-binaries-for-nix explicitly.
Fix#115073
elaborate a bit on the (lack of) safety in 'Mmap::map'
Sadly none of the callers of this function even consider it worth mentioning in their unsafe block that what they are doing is completely unsound.
resolve: Stop creating `NameBinding`s on every use, create them once per definition instead
`NameBinding` values are supposed to be unique, use referential equality, and be created once for every name declaration.
Before this PR many `NameBinding`s were created on name use, rather than on name declaration, because it's sufficiently cheap, and comparisons are not actually used in practice for some binding kinds.
This PR makes `NameBinding`s consistently unique and created on name declaration.
There are two special cases
- for extern prelude names creating `NameBinding` requires loading the corresponding crate, which is expensive, so such bindings are created lazily on first use, but they still keep the uniqueness by being reused on further uses.
- for legacy derive helpers (helper attributes written before derives that introduce them) the declaration and the use is basically the same thing (that's one of the reasons why they are deprecated), so they are still created on use, but we can still maybe do a bit better in a way that I described in FIXME in the last commit.
Update changelog stable note
Roses are red,
violets are blue,
new release,
tiny todo
---
---
changelog: none
new lint: `implied_bounds_in_impls`
Closes#10849
A new lint that looks for explicitly specified bounds that are already implied by other bounds in `impl Trait` return position types.
One example, as shown in the linked example, would be
```rs
fn foo<T>(x: T) -> impl Deref<Target = T> + DerefMut<Target = T> {
Box::new(x)
}
```
`DerefMut<Target = T>` requires `Deref<Target = T>` to be wellformed, so specifying `Deref` there is unnecessary.
This currently "ignores" (i.e., does not lint at all) transitive supertrait bounds (e.g. `trait A {} trait B: A {} trait C: B {}`, then having an `impl A + C` type), because that seems a bit more difficult and I think this isn't technically a blocker. It leads to FNs, but shouldn't bring any FPs
changelog: new lint [`implied_bounds_in_impls`]
Fix races conditions with `SyntaxContext` decoding
This changes `SyntaxContext` decoding to work with concurrent decoding. The `remapped_ctxts` field now only stores `SyntaxContext` which have completed decoding, while the new `decoding` and `local_in_progress` keeps track of `SyntaxContext`s which are in process of being decoding and on which threads.
This fixes 2 issues with the current implementation. It can return an `SyntaxContext` which contains dummy data if another thread starts decoding before the first one has completely finished. Multiple threads could also allocate multiple `SyntaxContext`s for the same `raw_id`.
Suggest mutable borrow on read only for-loop that should be mutable
```
error[E0596]: cannot borrow `*test` as mutable, as it is behind a `&` reference
--> $DIR/suggest-mut-iterator.rs:22:9
|
LL | for test in &tests {
| ------ this iterator yields `&` references
LL | test.add(2);
| ^^^^ `test` is a `&` reference, so the data it refers to cannot be borrowed as mutable
|
help: use a mutable iterator instead
|
LL | for test in &mut tests {
| +++
```
Fix#114311.
Parse unnamed fields and anonymous structs or unions (no-recovery)
It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions.
r? `@petrochenkov`
