…ompiler-errors

make unsupported_calling_conventions a hard error

This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang/rust#86231 (comment)) even when the lint was originally added.

This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.)

Fixes rust-lang/rust#87678

terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)

Mostly, we currently call a feature that has a corresponding `#[feature(name)]` attribute in the current crate a "declared" feature. I think that is confusing as it does not align with what "declaring" usually means. Furthermore, we *also* refer to `#[stable]`/`#[unstable]` as *declaring* a feature (e.g. in [these diagnostics](https://github.com/rust-lang/rust/blob/f25e5abea229a6b6aa77b45e21cb784e785c6040/compiler/rustc_passes/messages.ftl#L297-L301)), which aligns better with what "declaring" usually means. To make things worse, the functions  `tcx.features().active(...)` and  `tcx.features().declared(...)` both exist and they are doing almost the same thing (testing whether a corresponding `#[feature(name)]`  exists) except that `active` would ICE if the feature is not an unstable lang feature. On top of this, the callback when a feature is activated/declared is called `set_enabled`, and many comments also talk about "enabling" a feature.

So really, our terminology is just a mess.

I would suggest we use "declaring a feature" for saying that something is/was guarded by a feature (e.g. `#[stable]`/`#[unstable]`), and "enabling a feature" for  `#[feature(name)]`. This PR implements that.

x86-32 float return for 'Rust' ABI: treat all float types consistently

This helps with rust-lang/rust#131819: for our own ABI on x86-32, we want to *never* use the float registers. The previous logic only considered F32 and F64, but skipped F16 and F128. So I made the logic just apply to all float types.

try-job: i686-gnu
try-job: i686-gnu-nopt

better default capacity for str::replace

Adds smarter capacity for str::replace in cases where we know that the output will be at least as long as the original string.

…illaumeGomez

rustdoc: hash assets at rustdoc build time

Since sha256 is slow enough to show up on small benchmarks, we can save time by embedding the hash in the executable.

Addresses rust-lang/rust#131934 (comment)

Remove the `Arc` rt::init allocation for thread info

Removes an allocation pre-main by just not storing anything in std::thread::Thread for the main thread.
- The thread name can just be a hard coded literal, as was done in #123433.
- Storing ThreadId and Parker in a static that is initialized once at startup. This uses SyncUnsafeCell and MaybeUninit as this is quite performance critical and we don't need synchronization or to store a tag value and possibly leave in a panic.

Update books

## rust-lang/edition-guide

7 commits in c7ebae25cb4801a31b6f05353f6d85bfa6feedd1..1f07c242f8162a711a5ac5a4ea8fa7ec884ee7a9
2024-10-21 14:29:49 UTC to 2024-10-19 19:08:20 UTC

- 2024: Add reserved syntax (rust-lang/edition-guide#326)
- Update stdout of `cargo new` (rust-lang/edition-guide#327)
- Don't run doctests on rustfmt ident sorting page
- add rustfmt raw identifer sorting doc (rust-lang/edition-guide#321)
- Add some tips for what to be careful of with rustdoc-doctests (rust-lang/edition-guide#323)
- Remove cargo-remove-implicit-features (rust-lang/edition-guide#324)
- Rename doctest standalone tag (rust-lang/edition-guide#325)

## rust-embedded/book

1 commits in f40a8b420ec4b4505d9489965e261f1d5c28ba23..ddbf1b4e2858fedb71b7c42eb15c4576517dc125
2024-10-13 19:53:37 UTC to 2024-10-13 19:53:37 UTC

- Add link to Cortex-M comparison to install.md (rust-embedded/book#378)

## rust-lang/reference

29 commits in c64e52a3d306eac0129f3ad6c6d8806ab99ae2e9..23ce619966541bf2c80d45fdfeecf3393e360a13
2024-10-05 00:33:03 +0000 to 2024-10-22 21:34:51 +0000
- Mention `--print cfg` under set configuration options (rust-lang/reference#1636)
- Fix `pat` fragment specifier to be the "current" edition (rust-lang/reference#1640)
- Add restriction for cfg_attr with crate_type and crate_name (rust-lang/reference#1649)
- Sort macro fragment specifiers (rust-lang/reference#1641)
- Document mixed-site hygiene (rust-lang/reference#1656)
- Clarify that "macro attributes" refers to proc macros (rust-lang/reference#1660)
- mdbook-spec: Fix Spec::new creation (rust-lang/reference#1658)
- Fix stdcall example broken by recent rustc change (rust-lang/reference#1659)
- Add spec identifiers to const_eval.md (rust-lang/reference#1569)
- Add identifier syntax to trait-bounds.md (rust-lang/reference#1631)
- Add identifier syntax to macro-ambiguity.md (rust-lang/reference#1634)
- Add spec identifier syntax to conditional-compilation.md (rust-lang/reference#1564)
- Add spec identifiers to behaviour-considered-undefined.md (rust-lang/reference#1562)
- Add test linking (rust-lang/reference#1646)
- Allow `deny` inside `forbid` as a no-op (rust-lang/reference#1655)
- Add identifier syntax to identifiers.md (rust-lang/reference#1583)
- Add spec identifiers to crates-and-source-files.md (rust-lang/reference#1570)
- Add identifier syntax to linkage.md (rust-lang/reference#1633)
- Add identifier syntax to type-coercions.md (rust-lang/reference#1632)
- Add identifiers to variables.md (rust-lang/reference#1626)
- Add identifier syntax to lexer chapters (rust-lang/reference#1620)
- Add spec identifier syntax to `unsafe-keyword.md` and `unsafety.md` (rust-lang/reference#1619)
- Add identifier syntax to types and subchapters. (rust-lang/reference#1618)
- Add identifier syntax to subtyping.md (rust-lang/reference#1613)
- Add identifier syntax to statements.md (rust-lang/reference#1611)
- Add identifier syntax to type-layout.md (rust-lang/reference#1614)
- Clarify definition of "immutable bytes" (rust-lang/reference#1637)
- Add preview artifacts in CI (rust-lang/reference#1647)
- trait bounds grammar: make `?` and `for<>` mutually exclusive (rust-lang/reference#1650)

## rust-lang/rustc-dev-guide

5 commits in 07bc9ca9eb1cd6d9fbbf758c2753b748804a134f..59d94ea75a0b157e148af14c73c2dd60efb7b60a
2024-10-21 02:30:07 UTC to 2024-10-07 21:12:09 UTC

- Add the WASM | WASI | Emscripten notification groups (rust-lang/rustc-dev-guide#2100)
- Update bootstrapping.md (rust-lang/rustc-dev-guide#1900)
- Rename `needs-profiler-support` to `needs-profiler-runtime` (rust-lang/rustc-dev-guide#2095)
- Document compiletest directives `ignore-coverage-map` and `ignore-coverage-run` (rust-lang/rustc-dev-guide#2094)
- Purge `run-pass-valgrind` mentions (rust-lang/rustc-dev-guide#2091)

Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature

On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)

As discussed in rust-lang/lang-team#235, this turns out to very easily lead to unsound code.

This commit makes it a post-monomorphization error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.

See the [nomination comment](rust-lang/rust#127731 (comment)) for more discussion.

r? RalfJung

Part of rust-lang/rust#116558

(Big performance change) Do not run lints that cannot emit

Before this change, adding a lint was a difficult matter because it always had some overhead involved. This was because all lints would run, no matter their default level, or if the user had `#![allow]`ed them. This PR changes that. This change would improve both the Rust lint infrastructure and Clippy, but Clippy will see the most benefit, as it has about 900 registered lints (and growing!)

So yeah, with this little patch we filter all lints pre-linting, and remove any lint that is either:
- Manually `#![allow]`ed in the whole crate,
- Allowed in the command line, or
- Not manually enabled with `#[warn]` or similar, and its default level is `Allow`

As some lints **need** to run, this PR also adds **loadbearing lints**. On a lint declaration, you can use the ``@eval_always` = true` marker to label it as loadbearing. A loadbearing lint will never be filtered (it will always run)

Fixes #106983

Add an unstable `const_sockaddr_setters` feature

Unstably add `const` to the `sockaddr_setters` methods. Included API:

```rust
// core::net

impl SocketAddr {
    pub const fn set_ip(&mut self, new_ip: IpAddr);
    pub const fn set_port(&mut self, new_port: u16);
}

impl SocketAddrV4 {
    pub const fn set_ip(&mut self, new_ip: Ipv4Addr);
    pub const fn set_port(&mut self, new_port: u16);
}

impl SocketAddrV6 {
    pub const fn set_ip(&mut self, new_ip: Ipv6Addr);
    pub const fn set_port(&mut self, new_port: u16);
}
```

Tracking issue: <rust-lang/rust#131714>

rustc_target: Add pauth-lr aarch64 target feature

Add the pauth-lr target feature, corresponding to aarch64 FEAT_PAuth_LR. This feature has been added in LLVM 19.
It is currently not supported by the Linux hwcap and so we cannot add runtime feature detection for it at this time.

r? `@Amanieu`

Miri subtree update

r? `@ghost`

Rollup of 5 pull requests

Successful merges:

 - #132043 (Simplify param handling in `resolve_bound_vars`)
 - #132214 (Cleanup: Move an impl-Trait check from AST validation to AST lowering)
 - #132221 (Clean up some comments on lint implementation)
 - #132228 (Revert "ci update freebsd version proposal, freebsd 12 being eol.")
 - #132234 (Miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup

…Jung

Make clearer that guarantees in ABI compatibility are for Rust only

cc rust-lang/rust#132136 (comment) -- it looks like we already had a note that I missed in my initial look here, but this goes further to emphasize the guarantees, including uplifting it to the top of the general documentation.

r? `@RalfJung`

bump stdarch

This lets us remove a hack from rust-lang/rust#131349.

r? `@Amanieu`

try-job: test-various

After moving some `Box` internals to a different module,
the path in the diagnostic changed.

Lint against getting pointers from immediately dropped temporaries

Fixes #123613

## Changes:
1. New lint: `dangling_pointers_from_temporaries`. Is a generalization of `temporary_cstring_as_ptr` for more types and more ways to get a temporary.
2. `temporary_cstring_as_ptr` is removed and marked as renamed to `dangling_pointers_from_temporaries`.
3. `clippy::temporary_cstring_as_ptr` is marked as renamed to `dangling_pointers_from_temporaries`.
4. Fixed a false positive[^fp] for when the pointer is not actually dangling because of lifetime extension for function/method call arguments.
5. `core::cell::Cell` is now `rustc_diagnostic_item = "Cell"`

## Questions:
- [ ]  Instead of manually checking for a list of known methods and diagnostic items, maybe add some sort of annotation to those methods in library and check for the presence of that annotation? rust-lang/rust#128985 (comment)

## Known limitations:

### False negatives[^fn]:

See the comments in `compiler/rustc_lint/src/dangling.rs`

1. Method calls that are not checked for:
   - `temporary_unsafe_cell.get()`
   - `temporary_sync_unsafe_cell.get()`
2. Ways to get a temporary that are not recognized:
   - `owning_temporary.field`
   - `owning_temporary[index]`
3. No checks for ref-to-ptr conversions:
   - `&raw [mut] temporary`
   - `&temporary as *(const|mut) _`
    - `ptr::from_ref(&temporary)` and friends

[^fn]: lint **should** be emitted, but **is not**

[^fp]: lint **should not** be emitted, but **is**

compiler: apply clippy::clone_on_ref_ptr for CI

Apply lint https://rust-lang.github.io/rust-clippy/master/index.html#/clone_on_ref_ptr for compiler, also see rust-lang/rust#131225 (comment).

Some Arc's can be misplaced with Lrc's, sorry.

https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/enable.20more.20clippy.20lints.20for.20compiler.20.28and.5Cor.20std.29

Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.

Tracking issues: #131516, #131518

First commit implements `const_is_char_boundary`, second commit implements `const_str_split_at` (which depends on `const_is_char_boundary`)

~~I used `const_eval_select` for `is_char_boundary` since there is a comment about optimizations that would theoretically not happen with the simple `const`-compatible version (since `slice::get` is not `const`ifiable) cc #84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.~~

This changes `str::split_at_checked` to use a new private helper function `split_at_unchecked` (copied from `split_at_mut_unchecked`) that does pointer stuff instead of `get_unchecked`, since that is not currently `const`ifiable due to using the `SliceIndex` trait.

Collect item bounds for RPITITs from trait where clauses just like associated types

We collect item bounds from trait where clauses for *associated types*, i.e. this:

```rust
trait Foo
where
    Self::Assoc: Send
{
    type Assoc;
}
```

Becomes this:

```rust
trait Foo {
    type Assoc: Send;
}
```

Today, with RPITITs/AFIT and return-type notation, we don't do that, i.e.:

```rust
trait Foo where Self::method(..): Send {
    fn method() -> impl Sized;
}

fn is_send(_: impl Send) {}
fn test<T: Foo>() {
    is_send(T::method());
}
```

...which fails on nightly today.

 Turns out it's super easy to fix this, and we just need to use the `associated_type_bounds` lowering function in `explicit_item_bounds_with_filter`, which has that logic baked in.

correct LLVMRustCreateThinLTOData arg types

`LLVMRustCreateThinLTOData` defined in rust as
```rust
    pub fn LLVMRustCreateThinLTOData(
        Modules: *const ThinLTOModule,
        NumModules: c_uint,
        PreservedSymbols: *const *const c_char,
        PreservedSymbolsLen: c_uint,
    ) -> Option<&'static mut ThinLTOData>;
```
but in cpp as
```cpp
extern "C" LLVMRustThinLTOData *
LLVMRustCreateThinLTOData(LLVMRustThinLTOModule *modules, int num_modules,
                          const char **preserved_symbols, int num_symbols) {
```

(note `c_unit` vs `int` types). Let it be actually `size_t`.

Also fixes return type of `LLVMRustDIBuilderCreateOpLLVMFragment` to uint64_t as other similar functions around, which should be correct, i assume.

…ilee

Split `boxed.rs` into a few modules

I wanted to add an impl for `Box<_>`, but was quickly discouraged by the 3K file. This splits off a couple bits, making it at least a bit more manageable.

r? ````@workingjubilee```` (I think you are not bothered by refactorings like this?)

…beetrees,workingjubilee

riscv-soft-abi-with-float-features.rs: adapt for LLVM 20

Adapts a test for LLVM 20. No functional changes intended.

clarified doc for `std::fs::OpenOptions.truncate()`

Clarified what method does when `std::fs::OpenOptions.truncate()` parameter is set to `true`.

Remove my ping for rustdoc/clean/types.rs

It was useful at one time, but now it just causes notification noise.

Remove myself from mentions inside `tests/ui/check-cfg` directory

This PR removes myself from mentions inside `tests/ui/check-cfg` directory.

I'm not sure this particular mention has ever been useful to me, and lately it's been too annoying for me to ignore it.

So remove my-self from it.

Delete `tests/crashes/23707.rs` because it's flaky

It's conditioned on `only-x86_64` because it doesn't reliably fail on other platforms, it's optimization dependent and failed to ICE post-PGO in
<rust-lang/rust#132300 (comment)>. Remove this test for now without prejudice against relanding the test in a more reliable form.

I removed the `S-bug-has-test` label from #23707.

r? compiler

compiletest: Rename `command-list.rs` to `directive-list.rs`

Because I forget the name of this file literally every single time I need to find and edit it.

r? jieyouxu

Rollup of 12 pull requests

Successful merges:

 - #131375 (compiler: apply clippy::clone_on_ref_ptr for CI)
 - #131520 (Mark `str::is_char_boundary` and `str::split_at*` unstably `const`.)
 - #132119 (Hack out effects support for old solver)
 - #132194 (Collect item bounds for RPITITs from trait where clauses just like associated types)
 - #132216 (correct LLVMRustCreateThinLTOData arg types)
 - #132233 (Split `boxed.rs` into a few modules)
 - #132266 (riscv-soft-abi-with-float-features.rs: adapt for LLVM 20)
 - #132270 (clarified doc for `std::fs::OpenOptions.truncate()`)
 - #132284 (Remove my ping for rustdoc/clean/types.rs)
 - #132293 (Remove myself from mentions inside `tests/ui/check-cfg` directory)
 - #132312 (Delete `tests/crashes/23707.rs` because it's flaky)
 - #132313 (compiletest: Rename `command-list.rs` to `directive-list.rs`)

r? `@ghost`
`@rustbot` modify labels: rollup

Rc/Arc: don't leak the allocation if drop panics

Currently, when the last `Rc<T>` or `Arc<T>` is dropped and the destructor of `T` panics, the allocation will be leaked. This leak is unnecessary since the data cannot be (safely) accessed again and `Box` already deallocates in this case, so let's do the same for `Rc` and `Arc`, too.

Use Hacker's Delight impl in `i64::midpoint` instead of wide `i128` impl

This PR switches `i64::midpoint` and (`isize::midpoint` where `isize == i64`) to using our Hacker's Delight impl instead of wide `i128` implementation.

As LLVM seems to be outperformed by the complexity of signed 128-bits number compared to our Hacker's Delight implementation.[^1]

It doesn't seems like it's an improvement for the other sizes[^2], so we let them with the wide implementation.

[^1]: https://rust.godbolt.org/z/ravE75EYj
[^2]: https://rust.godbolt.org/z/fzr171zKh

r? libs