Rollup of 6 pull requests
Successful merges:
- #126908 (Use Cow<'static, str> for InlineAsmTemplatePiece::String)
- #127999 (Inject arm32 shims into Windows metadata generation)
- #128137 (CStr: derive PartialEq, Eq; add test for Ord)
- #128185 (Fix a span error when parsing a wrong param of function.)
- #128187 (Fix 1.80.0 version in RELEASES.md)
- #128189 (Turn an unreachable code path into an ICE)
r? `@ghost`
`@rustbot` modify labels: rollup
Turn an unreachable code path into an ICE
We're probably replacing the resolution with a `Res::Err` nowadays instead of just erroring but keeping the `Res`, so this code path should be unreachable
Fix a span error when parsing a wrong param of function.
fixes#128042
Before this change, the span of param `*mut Self` in `fn oof(*mut Self)` contains `(` before it, so the suggestion in E0424 will be error.
CStr: derive PartialEq, Eq; add test for Ord
While working on #128046, I've spotted a peculiarity: `CStr` has `PartialEq, Eq, PartialOrd, Ord` implemented manually and not derived.
While we can't derive `PartialOrd, Ord` (due to inner `[c_char]` being `[i8]` or `[u8]` on different platforms), we *can* derive `PartialEq, Eq` (I think), allowing as to remove `#[allow(clippy::derived_hash_with_manual_eq)]` as well.
(I really hope `c_char: Eq` on all platforms)
Inject arm32 shims into Windows metadata generation
I had been keen to eventually move to using windows-sys as a normal Cargo dependency. But for linking, compile times and other reasons that's unlikely to ever happen.
So if we're sticking with generated bindings then injecting any necessary missing type definitions (i.e. for the MS unsupported arm32) is simpler than defining whole functions ourselves just because we need to manually implement those types on a tier 3 platform. This also reduces the places we need to change when making changes to how we use `#[link]`.
r? libs
Rollup of 7 pull requests
Successful merges:
- #121364 (Implement lint against ambiguous negative literals)
- #127300 (Fix connect timeout for non-linux targets, read readiness of socket connection, Read readiness to detect errors. `Fixes #127018`)
- #128138 (`#[naked]`: use an allowlist for allowed options on `asm!` in naked functions)
- #128158 (std: unsafe-wrap personality::gcc)
- #128171 (Make sure that args are compatible in `resolve_associated_item`)
- #128172 (Don't ICE if HIR and middle types disagree in borrowck error reporting)
- #128173 (Remove crashes for misuses of intrinsics)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove crashes for misuses of intrinsics
All of these do not crash if the feature gate is removed. An ICE due *opting into* the intrinsics feature gate is not a bug that needs to be fixed, but instead a misuse of an internal-only API.
See https://github.com/rust-lang/compiler-team/issues/620
The last two issues are already closed anyways, but:
Fixes#97501Fixes#111699Fixes#101962
Don't ICE if HIR and middle types disagree in borrowck error reporting
We try to match up the `middle::ty::Ty` and `hir::Ty` types in borrowck error reporting, but due to things like `Self` self type alias, or regular type aliases, these might not match up. Don't ICE.
This PR also tries to recover the error by looking up the self type of the impl in case we see `Self`. The diagnostic is frankly quite confusing, but I also didn't really want to look at it because I don't understand the conflict error reporting logic. 🤷Fixes#121816
Make sure that args are compatible in `resolve_associated_item`
Implements a similar check to the one that we have in projection for GATs (#102488, #123240), where we check that the args of an impl item are compatible before returning it. This is done in `resolve_assoc_item`, which is backing `Instance::resolve`, so this is conceptually generalizing the check from GATs to methods/assoc consts. This is important to make sure that the inliner will only visit and substitute MIR bodies that are compatible w/ their trait definitions.
This shouldn't happen in codegen, but there are a few ways to get the inliner to be invoked (via calls to `optimized_mir`) before codegen, namely polymorphization and CTFE.
Fixes#121957Fixes#120792Fixes#120793Fixes#121063
std: unsafe-wrap personality::gcc
Nothing seems obviously wrong with these implementations except for some unanswered questions. Admittedly, I don't want to burn excessive time on exceptional exception handlers. Thus this is mostly a brute-force syntactic wrapping and some comments where they seemed correct, creating another largely whitespace diff.
try-job: armhf-gnu
`#[naked]`: use an allowlist for allowed options on `asm!` in naked functions
tracking issue: https://github.com/rust-lang/rust/issues/90957
this is mostly just a refactor, but using an allowlist (rather than a denylist) for which asm options are allowed in naked functions is a little safer.
These options are disallowed because naked functions are effectively global asm, but defined using inline asm.
Fix connect timeout for non-linux targets, read readiness of socket connection, Read readiness to detect errors. `Fixes #127018`
Fixes#127018
Connect_timeout would call `poll` and check `pollfd.revents` for POLLHUP error, rather that checking readiness. This behavior was meant for Linux as it returns POLLHUP | POLLOUT | POLLERR in case of errors. But on targets that do not return POLLHUP in `pollfd.revents`, this would indicate a false success and result in this issue. To resolve this we will check readiness of socket using `getsockopt():` and return success from connect_timeout when there are no errors.
Changes were tested on Linux and an rtos.
Thank you.
Implement lint against ambiguous negative literals
This PR implements a lint against ambiguous negative literals with a literal and method calls right after it.
## `ambiguous_negative_literals`
(deny-by-default)
The `ambiguous_negative_literals` lint checks for cases that are confusing between a negative literal and a negation that's not part of the literal.
### Example
```rust,compile_fail
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```
### Explanation
Method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.
<details>
<summary>Old proposed lint</summary>
## `ambiguous_unary_precedence`
(deny-by-default)
The `ambiguous_unary_precedence` lint checks for use the negative unary operator with a literal and method calls.
### Example
```rust
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```
### Explanation
Unary operations take precedence on binary operations and method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.
</details>
-----
Note: This is a strip down version of https://github.com/rust-lang/rust/pull/117161, without the binary op precedence.
Fixes https://github.com/rust-lang/rust/issues/117155
`@rustbot` labels +I-lang-nominated
cc `@scottmcm`
r? compiler
compiler: Never debug_assert in codegen
In the name of Turing and his Hoarey heralds, assert our truths before creating a monster!
The `rustc_codegen_llvm` and `rustc_codegen_ssa` crates are fairly critical for rustc's correctness. Small mistakes here can easily result in undefined behavior, since a "small mistake" can mean something like "link and execute the wrong code". We should probably run any and all asserts in these modules unconditionally on whether this is a "debug build", and damn the costs in performance.
...Especially because the costs in performance seem to be *nothing*. It is not clear how much correctness we gain here, but I'll take free correctness improvements.
Rollup of 5 pull requests
Successful merges:
- #127054 (Reorder trait bound modifiers *after* `for<...>` binder in trait bounds)
- #127528 (Replace ASCII control chars with Unicode Control Pictures)
- #127872 (Migrate `pointer-auth-link-with-c`, `c-dynamic-rlib` and `c-dynamic-dylib` `run-make` tests to rmake)
- #128111 (Do not use question as label)
- #128160 (Don't ICE when auto trait has assoc ty in old solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE when auto trait has assoc ty in old solver
Kinda a pointless change to make, but it's observable w/o the feature gate, so let's just fix it. I reintroduced this ICE when I removed the "auto impl" kind from `ImplSource` in #112687.
Fixes#117829Fixes#127746
Do not use question as label
We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might":
```
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
| ^^^^ you might be missing crate `spam`
|
= help: consider adding `extern crate spam` to use the `spam` crate
```
Migrate `pointer-auth-link-with-c`, `c-dynamic-rlib` and `c-dynamic-dylib` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: i686-mingw
try-job: aarch64-apple
Replace ASCII control chars with Unicode Control Pictures
Replace ASCII control chars like `CR` with Unicode Control Pictures like `␍`:
```
error: bare CR not allowed in doc-comment
--> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32
|
LL | /// doc comment with bare CR: '␍'
| ^
```
Centralize the checking of unicode char width for the purposes of CLI display in one place. Account for the new replacements. Remove unneeded tracking of "zero-width" unicode chars, as we calculate these in the `SourceMap` as needed now.
Reorder trait bound modifiers *after* `for<...>` binder in trait bounds
This PR suggests changing the grammar of trait bounds from:
```
[CONSTNESS] [ASYNCNESS] [?] [BINDER] [TRAIT_PATH]
const async ? for<'a> Sized
```
to
```
([BINDER] [CONSTNESS] [ASYNCNESS] | [?]) [TRAIT_PATH]
```
i.e., either
```
? Sized
```
or
```
for<'a> const async Sized
```
(but not both)
### Why?
I think it's strange that the binder applies "more tightly" than the `?` trait polarity. This becomes even weirder when considering that we (or at least, I) want to have `async` trait bounds expressed like:
```
where T: for<'a> async Fn(&'a ()) -> i32,
```
and not:
```
where T: async for<'a> Fn(&'a ()) -> i32,
```
### Fallout
No crates on crater use this syntax, presumably because it's literally useless. This will require modifying the reference grammar, though.
### Alternatives
If this is not desirable, then we can alternatively keep parsing `for<'a>` after the `?` but deprecate it with either an FCW (or an immediate hard error), and begin parsing `for<'a>` *before* the `?`.
Rollup of 8 pull requests
Successful merges:
- #122192 (Do not try to reveal hidden types when trying to prove auto-traits in the defining scope)
- #126042 (Implement `unsigned_signed_diff`)
- #126548 (Improved clarity of documentation for std::fs::create_dir_all)
- #127717 (Fix malformed suggestion for repeated maybe unsized bounds)
- #128046 (Fix some `#[cfg_attr(not(doc), repr(..))]`)
- #128122 (Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps`)
- #128135 (std: use duplicate thread local state in tests)
- #128140 (Remove Unnecessary `.as_str()` Conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might":
```
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
| ^^^^ you might be missing crate `spam`
|
= help: consider adding `extern crate spam` to use the `spam` crate
```
Mark `missing_fragment_specifier` as `FutureReleaseErrorReportInDeps`
We are moving toward forbidding `missing_fragment_specifier` either in edition 2024 or unconditionally. Make a first step toward this by ensuring crates that rely on the old behavior are reported when used as dependencies.
Tracking issue: <https://github.com/rust-lang/rust/issues/128143>
Fix malformed suggestion for repeated maybe unsized bounds
Fixes#127441
Now when we encounter something like `foo(a : impl ?Sized + ?Sized)`, instead of suggesting removal of both bounds and leaving `foo(a: impl )` behind, we suggest changing the first bound to `Sized` and removing the second bound, resulting in `foo(a: impl Sized)`.
Although the issue was reported for impl trait types, it also occurred with regular param bounds. So if we encounter `foo<T: ?Sized + ?Sized>(a: T)` we now detect that all the bounds are `?Sized` and therefore emit the suggestion to remove the entire predicate `: ?Sized + ?Sized` resulting in `foo<T>(a: T)`.
Lastly, if we encounter a situation where some of the bounds are something other than `?Sized`, then we emit separate removal suggestions for each `?Sized` bound. E.g. if we see `foo(a: impl ?Sized + Bar + ?Sized)` or `foo<T: ?Sized + Bar + ?Sized>(a: T)` we emit suggestions such that the user will be left with `foo(a : impl Bar)` or `foo<T: Bar>(a: T)` respectively.
Implement `unsigned_signed_diff`
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Implements https://github.com/rust-lang/rust/issues/126041
Do not try to reveal hidden types when trying to prove auto-traits in the defining scope
fixes#99793
this avoids the cycle error by just causing a selection error, which is not fatal. We pessimistically assume that freeze does not hold, which is always a safe assumption.
rustdoc: clean up and fix ord violations in item sorting
Based on https://github.com/rust-lang/rust/pull/128139 with a few minor changes:
- The name sorting function is changed to follow the [version sort] from the style guide
- the `cmp` function is redesigned to more obviously make a partial order, by always return `cmp()` of the same variable as the `!=` above
[version sort]: https://doc.rust-lang.org/nightly/style-guide/index.html#sorting
Based on e3fdafc263 with a few
minor changes:
- The name sorting function is changed to follow the [version sort]
from the style guide
- the `cmp` function is redesigned to more obviously make a
partial order, by always return `cmp()` of the same variable as
the `!=` above
[version sort]: https://doc.rust-lang.org/nightly/style-guide/index.html#sorting
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
We are moving toward forbidding `missing_fragment_specifier` either in
edition 2024 or unconditionally. Make a first step toward this by
ensuring crates that rely on the old behavior are reported when used as
dependencies.
Tracking issue: <https://github.com/rust-lang/rust/issues/128143>
