Migrate `static-dylib-by-default`, `sanitizer-dylib-link`, `sanitizer-cdylib-link` and `sanitizer-staticlib-link` `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: armhf-gnu
try-job: test-various
try-job: i686-msvc
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
The issue occurs because in some configurations of traits where one of them has Deref as a supertrait, RA's type inference algorithm fails to resolve the Deref::Target type, and instead uses a TyKind::BoundVar (i.e. an unknown type). This "autoderefed" type then incorrectly acts as if it implements all traits in scope.
The fix is to re-apply the same sanity-check that is done in iterate_method_candidates_with_autoref(), that is: don't try to resolve methods on unknown types. This same sanity-check is now done on each autoderefed type for which trait methods are about to be checked. If the autoderefed type is unknown, then the iterating of the trait methods for that type is skipped.
Includes a unit test that only passes after applying the fixes in this commit.
Includes a change to the assertion count in test syntax_highlighting::tests::benchmark_syntax_highlighting_parser as suggested by Lukas Wirth during review.
Includes a change to the sanity-check code as suggested by Florian Diebold during review.
Stabilize const `{integer}::from_str_radix` i.e. `const_int_from_str`
This PR stabilizes the feature `const_int_from_str`.
- ACP Issue: rust-lang/libs-team#74
- Implementation PR: rust-lang/rust#99322
- Part of Tracking Issue: rust-lang/rust#59133
API Change Diff:
```diff
impl {integer} {
- pub fn from_str_radix(src: &str, radix: u32) -> Result<Self, ParseIntError>;
+ pub const fn from_str_radix(src: &str, radix: u32) -> Result<Self, ParseIntError>;
}
impl ParseIntError {
- pub fn kind(&self) -> &IntErrorKind;
+ pub const fn kind(&self) -> &IntErrorKind;
}
```
This makes it easier to parse integers at compile-time, e.g.
the example from the Tracking Issue:
```rust
env!("SOMETHING").parse::<usize>().unwrap()
```
could now be achived with
```rust
match usize::from_str_radix(env!("SOMETHING"), 10) {
Ok(val) => val,
Err(err) => panic!("Invalid value for SOMETHING environment variable."),
}
```
rather than having to depend on a library that implements or manually implement the parsing at compile-time.
---
Checklist based on [Libs Stabilization Guide - When there's const involved](https://std-dev-guide.rust-lang.org/development/stabilization.html#when-theres-const-involved)
I am treating this as a [partial stabilization](https://std-dev-guide.rust-lang.org/development/stabilization.html#partial-stabilizations) as it shares a tracking issue (and is rather small), so directly opening the partial stabilization PR for the subset (feature `const_int_from_str`) being stabilized.
- [x] ping Constant Evaluation WG
- [x] no unsafe involved
- [x] no `#[allow_internal_unstable]`
- [ ] usage of `intrinsic::const_eval_select` rust-lang/rust#124625 in `from_str_radix_assert` to change the error message between compile-time and run-time
- [ ] [rust-labg/libs-api FCP](https://github.com/rust-lang/rust/pull/124941#issuecomment-2207021921)
Support ?Trait bounds in supertraits and dyn Trait under a feature gate
This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example:
```rust
#![feature(allow_maybe_polarity)]
...
trait Trait1 : ?Trait { ... } // ok
fn foo(_: Box<(dyn Trait2 + ?Trait)>) {} // ok
fn bar<T: ?Sized + ?Trait>(_: &T) {} // ok
```
Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762).
This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727)
Migrate `interdependent-c-libraries`, `compiler-rt-works-on-mingw` and `incr-foreign-head-span` `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).
try-job: aarch64-apple
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-mingw
try-job: x86_64-msvc
try-job: x86_64-gnu-llvm-18
Stop using `unsized_const_parameters` in core/std
`feature(unsized_const_parameters)` is an incomplete feature and should not be used by core/std as it makes it can make it significantly harder to evolve the feature. It also just generally opens the possibility of introducing bugs on stable through std's backdoor.
The only usage of this feature in std is the `simd_shuffle_intrinsic` added in #119213. It doesn't seem to be used anywhere as far as I can tell so it is removed in this PR. All tests and codegen logic etc have been kept however.
r? `@workingjubilee`
Switch from `derivative` to `derive-where`
This is a part of the effort to get rid of `syn 1.*` in compiler's dependencies: #109302
Derivative has not been maintained in nearly 3 years[^1]. It also depends on `syn 1.*`.
This PR replaces `derivative` with `derive-where`[^2], a not dead alternative, which uses `syn 2.*`.
A couple of `Debug` formats have changed around the skipped fields[^3], but I doubt this is an issue.
[^1]: https://github.com/mcarton/rust-derivative/issues/117
[^2]: https://lib.rs/crates/derive-where
[^3]: See the changes in `tests/ui`
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
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
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
