Commit Graph

9120 Commits

Author SHA1 Message Date
Eduardo Sánchez Muñoz
c09ed3e767 Make some float methods unstable const fn
Some float methods are now `const fn` under the `const_float_methods` feature gate.

In order to support `min`, `max`, `abs` and `copysign`, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval.
2024-10-15 10:46:33 +02:00
bors
88f311479d Auto merge of #131724 - matthiaskrgr:rollup-ntgkkk8, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #130608 (Implemented `FromStr` for `CString` and `TryFrom<CString>` for `String`)
 - #130635 (Add `&pin (mut|const) T` type position sugar)
 - #130747 (improve error messages for `C-cmse-nonsecure-entry` functions)
 - #131137 (Add 1.82 release notes)
 - #131328 (Remove unnecessary sorts in `rustc_hir_analysis`)
 - #131496 (Stabilise `const_make_ascii`.)
 - #131706 (Fix two const-hacks)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-15 05:02:38 +00:00
Matthias Krüger
731e360d15
Rollup merge of #130747 - folkertdev:c-cmse-nonsecure-entry-error-messages, r=compiler-errors
improve error messages for `C-cmse-nonsecure-entry` functions

fixes https://github.com/rust-lang/rust/issues/81347

tracking issue: https://github.com/rust-lang/rust/issues/75835

brings error messages and testing for `C-cmse-nonsecure-entry` in line with `C-cmse-nonsecure-call`.

r? `@compiler-errors`
2024-10-15 05:12:35 +02:00
Matthias Krüger
fb691b470a
Rollup merge of #130635 - eholk:pin-reborrow-sugar, r=compiler-errors
Add `&pin (mut|const) T` type position sugar

This adds parser support for `&pin mut T` and `&pin const T` references. These are desugared to `Pin<&mut T>` and `Pin<&T>` in the AST lowering phases.

This PR currently includes #130526 since that one is in the commit queue. Only the most recent commits (bd450027eb4a94b814a7dd9c0fa29102e6361149 and following) are new.

Tracking:

- #130494

r? `@compiler-errors`
2024-10-15 05:12:34 +02:00
Matthias Krüger
c99c4d4057
Rollup merge of #131710 - ShE3py:parse_format_apostrophes, r=compiler-errors
Remove `'apostrophes'` from `rustc_parse_format`

The rest of the compiler uses \`grave accents\`, while `rustc_parse_format` uses \`'apostrophes.'\`

Also makes the crate compile as a stand-alone:
```
~/rust/compiler/rustc_parse_format $ cargo check
   Compiling rustc_index_macros v0.0.0 (/home/lieselotte/rust/compiler/rustc_index_macros)
error[E0277]: `syn::Lit` doesn't implement `Debug`
  --> compiler/rustc_index_macros/src/newtype.rs:52:57
   |
52 |                         panic!("Specified multiple max: {old:?}");
   |                                                         ^^^^^^^ `syn::Lit` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `Debug` is not implemented for `syn::Lit`
   = note: this error originates in the macro `$crate::const_format_args` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: `syn::Lit` doesn't implement `Debug`
  --> compiler/rustc_index_macros/src/newtype.rs:64:74
   |
64 |                         panic!("Specified multiple debug format options: {old:?}");
   |                                                                          ^^^^^^^ `syn::Lit` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `Debug` is not implemented for `syn::Lit`
   = note: this error originates in the macro `$crate::const_format_args` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error: could not compile `rustc_index_macros` (lib) due to 2 previous errors
```
`@rustbot` label +A-diagnostics
2024-10-15 05:11:40 +02:00
Matthias Krüger
2e2c433be4
Rollup merge of #131702 - compiler-errors:method-lookup-trait-warning, r=jieyouxu
Suppress import errors for traits that couldve applied for method lookup error

Self-explanatory. I hit this quite often when refactoring in rustc, so even though this isn't really showing up as significant in the UI test suite, it probably will matter more for multi-module projects.
2024-10-15 05:11:39 +02:00
Matthias Krüger
bd649b4dd0
Rollup merge of #131675 - tdittr:update-unsupported-abi-message, r=compiler-errors
Update lint message for ABI not supported

Tracking issue: #130260

As requested in https://github.com/rust-lang/rust/pull/128784#pullrequestreview-2364026550 I updated the error message.

I could also change it to be the same message as if it was a hard error on a normal function:

> "`{abi}` is not a supported ABI for the current target"

Or would that get confusing when people try to google the error message?

r? compiler-errors
2024-10-15 05:11:38 +02:00
bors
785c83015c Auto merge of #129458 - EnzymeAD:enzyme-frontend, r=jieyouxu
Autodiff Upstreaming - enzyme frontend

This is an upstream PR for the `autodiff` rustc_builtin_macro that is part of the autodiff feature.

For the full implementation, see: https://github.com/rust-lang/rust/pull/129175

**Content:**
It contains a new `#[autodiff(<args>)]` rustc_builtin_macro, as well as a `#[rustc_autodiff]` builtin attribute.
The autodiff macro is applied on function `f` and will expand to a second function `df` (name given by user).
It will add a dummy body to `df` to make sure it type-checks. The body will later be replaced by enzyme on llvm-ir level,
we therefore don't really care about the content. Most of the changes (700 from 1.2k) are in `compiler/rustc_builtin_macros/src/autodiff.rs`, which expand the macro. Nothing except expansion is implemented for now.
I have a fallback implementation for relevant functions in case that rustc should be build without autodiff support. The default for now will be off, although we want to flip it later (once everything landed) to on for nightly. For the sake of CI, I have flipped the defaults, I'll revert this before merging.

**Dummy function Body:**
The first line is an `inline_asm` nop to make inlining less likely (I have additional checks to prevent this in the middle end of rustc. If `f` gets inlined too early, we can't pass it to enzyme and thus can't differentiate it.
If `df` gets inlined too early, the call site will just compute this dummy code instead of the derivatives, a correctness issue. The following black_box lines make sure that none of the input arguments is getting optimized away before we replace the body.

**Motivation:**
The user facing autodiff macro can verify the user input. Then I write it as args to the rustc_attribute, so from here on I can know that these values should be sensible. A rustc_attribute also turned out to be quite nice to attach this information to the corresponding function and carry it till the backend.
This is also just an experiment, I expect to adjust the user facing autodiff macro based on user feedback, to improve usability.

As a simple example of what this will do, we can see this expansion:
From:
```
#[autodiff(df, Reverse, Duplicated, Const, Active)]
pub fn f1(x: &[f64], y: f64) -> f64 {
    unimplemented!()
}
```
to
```
#[rustc_autodiff]
#[inline(never)]
pub fn f1(x: &[f64], y: f64) -> f64 {
    ::core::panicking::panic("not implemented")
}
#[rustc_autodiff(Reverse, Duplicated, Const, Active,)]
#[inline(never)]
pub fn df(x: &[f64], dx: &mut [f64], y: f64, dret: f64) -> f64 {
    unsafe { asm!("NOP"); };
    ::core::hint::black_box(f1(x, y));
    ::core::hint::black_box((dx, dret));
    ::core::hint::black_box(f1(x, y))
}
```
I will add a few more tests once I figured out why rustc rebuilds every time I touch a test.

Tracking:

- https://github.com/rust-lang/rust/issues/124509

try-job: dist-x86_64-msvc
2024-10-15 01:30:01 +00:00
Lieselotte
dda3066805
Remove 'apostrophes' from rustc_parse_format 2024-10-14 23:22:51 +02:00
Folkert de Vries
10aa255541 improve error messages for C-cmse-nonsecure-entry functions 2024-10-14 22:32:32 +02:00
Michael Goulet
c3b696dec9 Suppress import errors for traits that couldve applied in method lookup on error 2024-10-14 14:40:11 -04:00
Lieselotte
1364631584
rt::Argument: elide lifetimes 2024-10-14 20:24:30 +02:00
Michael Goulet
5a8405a5fa Don't report on_unimplemented for negative traits 2024-10-14 14:18:25 -04:00
Matthias Krüger
b8cdca8cce
Rollup merge of #131550 - compiler-errors:extern-diags, r=spastorino
Make some tweaks to extern block diagnostics

Self-explanatory. See the diagnostic changes; I hope they make them a bit more descriptive.

r? spastorino
2024-10-14 17:06:38 +02:00
Matthias Krüger
75231f8764
Rollup merge of #131430 - surechen:fix_130495, r=jieyouxu
Special treatment empty tuple when suggest adding a string literal in format macro.

For example:
```rust
let s = "123";
println!({}, "sss", s);
```
Suggest:
`println!("{:?} {} {}", {}, "sss", s);`

fixes #130170
2024-10-14 17:06:37 +02:00
Matthias Krüger
32062b4b8e
Rollup merge of #131384 - saethlin:precondition-tests, r=ibraheemdev
Update precondition tests (especially for zero-size access to null)

I don't much like the current way I've updated the precondition check helpers, but I couldn't come up with anything better. Ideas welcome.

I've organized `tests/ui/precondition-checks` mostly with one file per function that has `assert_unsafe_precondition` in it, with revisions that check each precondition. The important new test is `tests/ui/precondition-checks/zero-size-null.rs`.
2024-10-14 17:06:36 +02:00
Matthias Krüger
43bf4f1fd3
Rollup merge of #131332 - taiki-e:arm64ec-clobber-abi, r=Amanieu
Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly

Currently `clobber_abi` in Arm64EC inline assembly is implemented using `InlineAsmClobberAbi::AArch64NoX18`, but broken since it attempts to clobber registers that cannot be used in Arm64EC: https://godbolt.org/z/r3PTrGz5r

```
error: cannot use register `x13`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
 --> <source>:6:14
  |
6 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
  |              ^^^^^^^^^^^^^^^^

error: cannot use register `x14`: x13, x14, x23, x24, x28, v16-v31 cannot be used for Arm64EC
 --> <source>:6:14
  |
6 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
  |              ^^^^^^^^^^^^^^^^

<omitted the same errors for v16-v31>
```

Additionally, this disallows SVE-related registers per https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142.

cc ``@dpaoliello``

r? ``@Amanieu``

``@rustbot`` label O-windows O-AArch64 +A-inline-assembly
2024-10-14 17:06:35 +02:00
bors
17a19e684c Auto merge of #131672 - matthiaskrgr:rollup-gyzysj4, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #128967 (std::fs::get_path freebsd update.)
 - #130629 (core/net: add Ipv[46]Addr::from_octets, Ipv6Addr::from_segments.)
 - #131274 (library: Const-stabilize `MaybeUninit::assume_init_mut`)
 - #131473 (compiler: `{TyAnd,}Layout` comes home)
 - #131533 (emscripten: Use the latest emsdk 3.1.68)
 - #131593 (miri: avoid cloning AllocExtra)
 - #131616 (merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate)
 - #131660 (Also use outermost const-anon for impl items in `non_local_defs` lint)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-14 12:20:35 +00:00
Tamme Dittrich
b6b6c12819 Update lint message for ABI not supported 2024-10-14 10:02:33 +02:00
bors
f6648f252a Auto merge of #126557 - GrigorenkoPV:vec_track_caller, r=joboet
Add `#[track_caller]` to allocating methods of `Vec` & `VecDeque`

Part 4 in a lengthy saga.
r? `@joshtriplett` because they were the reviewer the last 3 times.
`@bors` rollup=never "[just in case this has perf effects, Vec is hot](https://github.com/rust-lang/rust/pull/79323#issuecomment-731866746)"

This was first attempted in #79323 by `@nvzqz.` It got approval from `@joshtriplett,` but rotted with merge conflicts and got closed.

Then it got picked up by `@Dylan-DPC-zz` in #83359. A benchmark was run[^perf], the results (after a bit of thinking[^thinking]) were deemed ok[^ok], but there was a typo[^typo] and the PR was made from a wrong remote in the first place[^remote], so #83909 was opened instead.

By the time #83909 rolled around, the methods in question had received some optimizations[^optimizations], so another perf run was conducted[^perf2]. The results were ok[^ok2]. There was a suggestion to add regression tests for panic behavior [^tests], but before it could be addressed, the PR fell victim to merge conflicts[^conflicts] and died again[^rip].

3 years have passed, and (from what I can tell) this has not been tried again, so here I am now, reviving this old effort.

Given how much time has passed and the fact that I've also touched `VecDeque` this time, it probably makes sense to
`@bors` try `@rust-timer`

[^perf]: https://github.com/rust-lang/rust/pull/83359#issuecomment-804450095
[^thinking]: https://github.com/rust-lang/rust/pull/83359#issuecomment-805286704
[^ok]: https://github.com/rust-lang/rust/pull/83359#issuecomment-812739031
[^typo]: https://github.com/rust-lang/rust/pull/83359#issuecomment-812750205
[^remote]: https://github.com/rust-lang/rust/pull/83359#issuecomment-814067119
[^optimizations]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813736593
[^perf2]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813825552
[^ok2]: https://github.com/rust-lang/rust/pull/83909#issuecomment-813831341
[^tests]: https://github.com/rust-lang/rust/pull/83909#issuecomment-825788964
[^conflicts]: https://github.com/rust-lang/rust/pull/83909#issuecomment-851173480
[^rip]: https://github.com/rust-lang/rust/pull/83909#issuecomment-873569771
2024-10-14 02:33:40 +00:00
surechen
ceced5322c Special treatment empty tuple when suggest adding a string literal in format macro.
For example:
```rust
let s = "123";
println!({}, "sss", s);
```
Suggest:
`println!("{:?} {} {}", {}, "sss", s);`

fixes #130170
2024-10-14 10:07:57 +08:00
Taiki Endo
d858dfedbb Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly 2024-10-14 05:30:45 +09:00
Urgau
b5e91a00c8 Also use outermost const-anon for impl items in non_local_defs lint 2024-10-13 18:14:29 +02:00
Trevor Gross
507dd637a3
Rollup merge of #131579 - jieyouxu:ui-panic-username, r=compiler-errors
Remap path prefix in the panic message of `tests/ui/meta/revision-bad.rs`

Otherwise `error-pattern` on the test run stderr can incorrectly match if the paths in panic backtrace has a matching substring (like if we look for `bar` in the error pattern, but the username is `baron`).

Tested locally by checking run output `./x test .\tests\ui\meta\revision-bad.rs -- -- --nocapture`:

```
--- stderr -------------------------------
thread 'main' panicked at remapped\meta\revision-bad.rs:14:5:
foo
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------------------------------------------
```

Fixes #130996.
2024-10-12 21:38:37 -05:00
Trevor Gross
c8b2f7e458
Rollup merge of #131120 - tgross35:stabilize-const_option, r=RalfJung
Stabilize `const_option`

This makes the following API stable in const contexts:

```rust
impl<T> Option<T> {
    pub const fn as_mut(&mut self) -> Option<&mut T>;
    pub const fn expect(self, msg: &str) -> T;
    pub const fn unwrap(self) -> T;
    pub const unsafe fn unwrap_unchecked(self) -> T;
    pub const fn take(&mut self) -> Option<T>;
    pub const fn replace(&mut self, value: T) -> Option<T>;
}

impl<T> Option<&T> {
    pub const fn copied(self) -> Option<T>
    where T: Copy;
}

impl<T> Option<&mut T> {
    pub const fn copied(self) -> Option<T>
    where T: Copy;
}

impl<T, E> Option<Result<T, E>> {
    pub const fn transpose(self) -> Result<Option<T>, E>
}

impl<T> Option<Option<T>> {
    pub const fn flatten(self) -> Option<T>;
}
```

The following functions make use of the unstable `const_precise_live_drops` feature:

- `expect`
- `unwrap`
- `unwrap_unchecked`
- `transpose`
- `flatten`

Fixes: <https://github.com/rust-lang/rust/issues/67441>
2024-10-12 21:38:35 -05:00
Trevor Gross
19f6c17df4 Stabilize const_option
This makes the following API stable in const contexts:

    impl<T> Option<T> {
        pub const fn as_mut(&mut self) -> Option<&mut T>;
        pub const fn expect(self, msg: &str) -> T;
        pub const fn unwrap(self) -> T;
        pub const unsafe fn unwrap_unchecked(self) -> T;
        pub const fn take(&mut self) -> Option<T>;
        pub const fn replace(&mut self, value: T) -> Option<T>;
    }

    impl<T> Option<&T> {
        pub const fn copied(self) -> Option<T>
        where T: Copy;
    }

    impl<T> Option<&mut T> {
        pub const fn copied(self) -> Option<T>
        where T: Copy;
    }

    impl<T, E> Option<Result<T, E>> {
        pub const fn transpose(self) -> Result<Option<T>, E>
    }

    impl<T> Option<Option<T>> {
        pub const fn flatten(self) -> Option<T>;
    }

The following functions make use of the unstable
`const_precise_live_drops` feature:

- `expect`
- `unwrap`
- `unwrap_unchecked`
- `transpose`
- `flatten`

Fixes: <https://github.com/rust-lang/rust/issues/67441>
2024-10-12 17:07:13 -04:00
Matthias Krüger
b9e083f86b
Rollup merge of #131567 - CastilloDel:reject-unstable-with-accepted-features, r=jieyouxu
Emit an error for unstable attributes that reference already stable features

Closes https://github.com/rust-lang/rust/issues/129814
2024-10-12 23:00:58 +02:00
Matthias Krüger
663da00876
Rollup merge of #131239 - VulnBandit:trait-vulnerability, r=lcnr
Don't assume traits used as type are trait objs in 2021 edition

Fixes #127548

When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case.
This PR fixes the bug where you don't need a trait object, so the error message was changed to:
```
error[E0782]: expected a type, found a trait
```
Also fixes some ICEs:
Fixes https://github.com/rust-lang/rust/issues/120241
Fixes https://github.com/rust-lang/rust/issues/120482
Fixes https://github.com/rust-lang/rust/issues/125512
2024-10-12 23:00:56 +02:00
Matthias Krüger
57be141f8a
Rollup merge of #128784 - tdittr:check-abi-on-fn-ptr, r=compiler-errors
Check ABI target compatibility for function pointers

Tracking issue: https://github.com/rust-lang/rust/issues/130260
Related tracking issue: #87678

Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent.

This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea.

Also this might break existing code, because we now emit extra errors. Does this require a crater run?

# Example
```rust
// build with: --target=x86_64-unknown-linux-gnu

// These raise E0570
extern "thiscall" fn foo() {}
extern "thiscall" { fn bar() }

// This did not raise any error
fn baz(f: extern "thiscall" fn()) { f() }
```

# Open Questions
* [x] Should this report a future incompatibility warning like #87678 ?
* [ ] Is this the best place to perform the check?
2024-10-12 23:00:55 +02:00
Trevor Gross
ca3c822068
Rollup merge of #131233 - joboet:stdout-before-main, r=tgross35
std: fix stdout-before-main

Fixes #130210.

Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.

This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
2024-10-12 11:08:43 -05:00
Trevor Gross
8a86f1dd8c
Rollup merge of #130954 - workingjubilee:stabilize-const-mut-fn, r=RalfJung
Stabilize const `ptr::write*` and `mem::replace`

Since `const_mut_refs` and `const_refs_to_cell` have been stabilized, we may now also stabilize the ability to write to places during const evaluation inside our library API. So, we now propose the `const fn` version of `ptr::write` and its variants. This allows us to also stabilize `mem::replace` and `ptr::replace`.
- const `mem::replace`: https://github.com/rust-lang/rust/issues/83164#issuecomment-2338660862
- const `ptr::write{,_bytes,_unaligned}`: https://github.com/rust-lang/rust/issues/86302#issuecomment-2330275266

Their implementation requires an additional internal stabilization of `const_intrinsic_forget`, which is required for `*::write*` and thus `*::replace`. Thus we const-stabilize the internal intrinsics `forget`, `write_bytes`, and `write_via_move`.
2024-10-12 11:08:42 -05:00
Trevor Gross
63a91db022
Rollup merge of #130870 - surechen:fix_130791, r=compiler-errors
Add suggestion for removing invalid path sep `::` in fn def

Add suggestion for removing invalid path separator `::` in function definition.

for example: `fn invalid_path_separator::<T>() {}`

fixes #130791
2024-10-12 11:08:42 -05:00
joboet
9f91c5099f
std: fix stdout-before-main
Fixes #130210.

Since #124881, `ReentrantLock` uses `ThreadId` to identify threads. This has the unfortunate consequence of breaking uses of `Stdout` before main: Locking the `ReentrantLock` that synchronizes the output will initialize the thread ID before the handle for the main thread is set in `rt::init`. But since that would overwrite the current thread ID, `thread::set_current` triggers an abort.

This PR fixes the problem by using the already initialized thread ID for constructing the main thread handle and allowing `set_current` calls that do not change the thread's ID.
2024-10-12 13:01:36 +02:00
Michael Goulet
c8b71ef3dd Also note for fields 2024-10-12 06:14:46 -04:00
Michael Goulet
5e8820caaa Add a note for ? on future in sync function 2024-10-12 06:14:45 -04:00
CastilloDel
497100a13c Emit an error for unstable attributes that reference already stable features
Add missing error annotations and .stderr file

Acknowledge comments
2024-10-12 10:19:24 +02:00
Jubilee Young
ddc367ded7 library: Stabilize const_ptr_write
Const-stabilizes:
- `write`
- `write_bytes`
- `write_unaligned`

In the following paths:
- `core::ptr`
- `core::ptr::NonNull`
- pointer `<*mut T>`

Const-stabilizes the internal `core::intrinsics`:
- `write_bytes`
- `write_via_move`
2024-10-12 00:02:36 -07:00
Trevor Gross
1f31925345
Rollup merge of #131565 - Urgau:non_local_def-rm-deprecate, r=compiler-errors
Remove deprecation note in the `non_local_definitions` lint

This PR removes the edition deprecation note emitted by the `non_local_definitions` lint.

Specifically this part:

```
= note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
```

because it [didn't make the cut](https://github.com/rust-lang/rust/issues/120363#issuecomment-2407833300) for the 2024 edition.

`@rustbot` label +L-non_local_definitions
2024-10-11 23:57:47 -04:00
Trevor Gross
fcbf4ac6f9
Rollup merge of #131546 - surechen:fix_129833, r=jieyouxu
Make unused_parens's suggestion considering expr's attributes.

For the expr with attributes,
like `let _ = (#[inline] || println!("Hello!"));`,
the suggestion's span should contains the attributes, or the suggestion will remove them.

fixes #129833
2024-10-11 23:57:46 -04:00
许杰友 Jieyou Xu (Joe)
1fe079bd62 Remap path refix in the panic message
Otherwise `error-pattern` on the test run stderr can incorrectly match
if e.g. the paths in panic backtrace has a matching substring (like if
we look for `bar` in the error pattern but username is `baron`).
2024-10-12 09:41:42 +08:00
surechen
1e8d6d1ec3 Make unused_parens's suggestion considering expr's attributes
For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, the suggestion's span should contains the attributes, or the suggestion will remove them.

fixes #129833
2024-10-12 09:32:25 +08:00
Jed Brown
0d8a978e8a intrinsics.fmuladdf{16,32,64,128}: expose llvm.fmuladd.* semantics
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.

https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic

MIRI support is included for f32 and f64.

The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.

I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
2024-10-11 15:32:56 -06:00
Urgau
77b3065ed2 Remove deprecation note in the non_local_definitions warning 2024-10-11 21:21:32 +02:00
Manuel Drehwald
7c37d2db98 Add pretty, ui, and feature-gate tests for the enzyme/autodiff frontend 2024-10-11 20:38:43 +02:00
VulnBandit
9a2772e1c2 Don't assume traits used as type are trait objs 2024-10-11 17:36:04 +02:00
Michael Goulet
d6391d5d4d Note what qualifier 2024-10-11 11:30:08 -04:00
Michael Goulet
c085071631 Remove unadorned 2024-10-11 11:30:08 -04:00
bors
f4966590d8 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
Matthias Krüger
e00f49db17
Rollup merge of #131498 - Urgau:transparent-const-anons, r=lcnr
Consider outermost const-anon in `non_local_def` lint

This PR change the logic for finding the parent of the `impl` definition in the `non_local_definitions` lint to consider multiple level of const-anon items, instead of only one currently.

I also took the opportunity to cleanup the related code.

cc ``@traviscross``
Fixes https://github.com/rust-lang/rust/issues/131474
2024-10-11 12:21:07 +02:00
Jonathan Dönszelmann
0a9c87b1f5
rename RcBox in other places too 2024-10-11 10:04:22 +02:00
Urgau
7e05da8d42 Consider outermost const-anon in non_local_def lint 2024-10-11 09:39:53 +02:00
Matthias Krüger
fa3dff3e24
Rollup merge of #131475 - fmease:compiler-mv-obj-safe-dyn-compat-2, r=jieyouxu
Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"

Follow-up to #130826.
Part of #130852.

1. 1st commit: Fix stupid oversights. Should've been part of #130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
2024-10-10 22:00:50 +02:00
Matthias Krüger
4f2af123eb
Rollup merge of #131033 - compiler-errors:precise-capturing-in-traits, r=spastorino
Precise capturing in traits

This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work.

Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though.

I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs.

r? types

Tracking issue:
* #130044
2024-10-10 22:00:48 +02:00
Matthias Krüger
edb669350a
Rollup merge of #130741 - mrkajetanp:detect-b16b16, r=Amanieu
rustc_target: Add sme-b16b16 as an explicit aarch64 target feature

LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.

Resolves https://github.com/rust-lang/rust/pull/129894.
2024-10-10 22:00:48 +02:00
Matthias Krüger
13976f1f25
Rollup merge of #130308 - davidtwco:tied-target-consolidation, r=wesleywiser
codegen_ssa: consolidate tied target checks

Fixes #105110.
Fixes #105111.

`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for checking if tied target features were partially enabled. This PR consolidates these checks into `rustc_codegen_ssa` in the `codegen_fn_attrs` query, which also is run pre-monomorphisation for each function, which ensures that this check is run for unused functions, as would be expected.

Also adds a test confirming that enabling one tied feature doesn't imply another - the appropriate error for this was already being emitted. I did a bisect and narrowed it down to two patches it was likely to be - something in #128796, probably #128221 or #128679.
2024-10-10 22:00:45 +02:00
Michael Goulet
36076ecdc7 Clarify implicit captures for RPITIT 2024-10-10 11:46:51 -07:00
Michael Goulet
a7dc98733d Add variances to RPITITs 2024-10-10 11:46:48 -07:00
Michael Goulet
b7297ac440 Add gate for precise capturing in traits 2024-10-10 11:44:11 -07:00
bors
8d94e06ec9 Auto merge of #131263 - compiler-errors:solver-relating, r=lcnr
Introduce SolverRelating type relation to the new solver

Redux of #128744.

Splits out relate for the new solver so that implementors don't need to implement it themselves.

r? lcnr
2024-10-10 14:59:40 +00:00
Matthias Krüger
02930953d8
Rollup merge of #131482 - compiler-errors:struct-res, r=lcnr
structurally resolve adts and tuples expectations too

r? lcnr
2024-10-10 12:49:21 +02:00
Matthias Krüger
a2c43eb806
Rollup merge of #131397 - RalfJung:const-escaping-ref-teach, r=chenyukang
fix/update teach_note from 'escaping mutable ref/ptr' const-check

The old note was quite confusing since it talked about statics, but the message is also shown for consts. So let's reword to something that is true for both of them.
2024-10-10 12:49:19 +02:00
Kajetan Puchalski
335f67b652 rustc_target: Add sme-b16b16 as an explicit aarch64 target feature
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
2024-10-10 10:24:57 +00:00
Michael Goulet
09da2ebd63 Move ty::Error branch into super_combine_tys 2024-10-10 06:07:51 -04:00
Michael Goulet
2a8f08083f Structurallyresolve adts and tuples expectations too 2024-10-10 00:34:06 -04:00
bors
df1b5d3cc2 Auto merge of #131466 - matthiaskrgr:rollup-3qtz83x, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #123951 (Reserve guarded string literals (RFC 3593))
 - #130827 (Library: Rename "object safe" to "dyn compatible")
 - #131383 (Add docs about slicing slices at the ends)
 - #131403 (Fix needless_lifetimes in rustc_serialize)
 - #131417 (Fix methods alignment on mobile)
 - #131449 (Decouple WASIp2 sockets from WasiFd)
 - #131462 (Mention allocation errors for `open_buffered`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-10 01:12:11 +00:00
Ben Kimock
a3606d7ee3 Add a test for zero-sized writes through null 2024-10-09 19:34:27 -04:00
Ben Kimock
84dacc1882 Add more precondition check tests 2024-10-09 19:34:27 -04:00
León Orell Valerian Liehr
20cebae312
UI tests: Rename "object safe" to "dyn compatible" 2024-10-10 01:13:29 +02:00
León Orell Valerian Liehr
2e7a52b22f
Rename feature object_safe_for_dispatch to dyn_compatible_for_dispatch 2024-10-10 00:57:59 +02:00
Matthias Krüger
b41e939cb5
Rollup merge of #123951 - pitaj:reserve-guarded-strings, r=traviscross
Reserve guarded string literals (RFC 3593)

Implementation for RFC 3593, including:
- lexer / parser changes
- diagnostics
- migration lint
- tests

We reserve `#"`, `##"`, `###"`, `####`, and any other string of four or more repeated `#`. This avoids infinite lookahead in the lexer, though we still use infinite lookahead in the parser to provide better forward compatibility diagnostics.

This PR does not implement any special lexing of the string internals:
- strings preceded by one or more `#` are denied
- regardless of the number of trailing `#`
- string contents are lexed as if it was just a bare `"string"`

Tracking issue: #123735
RFC: rust-lang/rfcs#3593
2024-10-09 23:03:47 +02:00
Matthias Krüger
f144469bda
Rollup merge of #131420 - compiler-errors:post-mono-layout-cycle, r=wesleywiser
Dont ICE when encountering post-mono layout cycle error

It's possible to encounter post-mono layout cycle errors in `fn_abi_of_instance`. Don't ICE in those cases.

This was originally discovered in an async fn, but that's not the only way to encounter such an error (which the other test I added should demonstrate).

Error messsages suck, but this fix is purely about suppressing the ICE.

Fixes #131409
2024-10-09 20:27:24 +02:00
Zalathar
622d5898c2 Rename directive needs-profiler-support to needs-profiler-runtime 2024-10-09 20:58:27 +11:00
Peter Jaszkowiak
321a5db7d4 Reserve guarded string literals (RFC 3593) 2024-10-08 18:21:16 -06:00
Michael Goulet
17eca60c24 Dont ICE when encountering post-mono layout cycle error 2024-10-08 16:46:16 -04:00
Ralf Jung
287eb03838 fix/update teach_note from 'escaping mutable ref/ptr' const-check 2024-10-08 14:03:03 +02:00
bors
cf24c73141 Auto merge of #126733 - ZhuUx:llvm-19-adapt, r=Zalathar
[Coverage][MCDC] Adapt mcdc to llvm 19

Related issue: #126672

Also finish task 4 at #124144

[llvm #82448](https://github.com/llvm/llvm-project/pull/82448) has introduced some break changes into mcdc, causing incompatibility between llvm 18 and 19. This draft adapts to that change and gives up supporting for llvm-18.
2024-10-08 07:08:41 +00:00
zhuyunxing
6e3e19f714 coverage. Adapt to mcdc mapping formats introduced by llvm 19 2024-10-08 11:15:24 +08:00
Stuart Cook
2da0d40389
Rollup merge of #131379 - ehuss:fix-utf8-bom, r=jieyouxu
Fix utf8-bom test

The BOM was accidentally removed in https://github.com/rust-lang/rust/pull/57108

I had to move the run-pass line down, because compiletest doesn't seem to know about BOMs, so it does not parse the header if it is the first line.
2024-10-08 13:19:45 +11:00
Stuart Cook
cc5a24caf6
Rollup merge of #131355 - clubby789:old-tests, r=jieyouxu
Add tests for some old fixed issues

Closes #30867
Closes #30472
Closes #28994
Closes #26719 (and migrates the relevant test to the new run-make)
Closes #23600

cc `@jieyouxu` for the run-make-support changes

try-job: x86_64-msvc
2024-10-08 13:19:44 +11:00
Nadrieril
2ef0a8fdfd Change error message 2024-10-08 00:23:28 +02:00
Nadrieril
4aaada42d0 Stabilize min_match_ergonomics_2024 2024-10-08 00:23:28 +02:00
Nadrieril
575033c50c Also disallow ref/ref mut overriding the binding mode 2024-10-08 00:23:28 +02:00
Nadrieril
4107322766 Error on resetted binding mode in edition 2024 2024-10-08 00:23:28 +02:00
Eric Huss
89b0f8a689 Fix utf8-bom test
The BOM was accidentally removed in https://github.com/rust-lang/rust/pull/57108
2024-10-07 14:45:49 -07:00
Nadrieril
4abbdfa1c9 Prepare tests 2024-10-07 23:11:06 +02:00
Eric Holk
ae698f8199
Add sugar for &pin (const|mut) types 2024-10-07 11:15:04 -07:00
Jubilee
bd2e7ee976
Rollup merge of #128721 - Brezak:pointee-in-strange-places, r=pnkfelix
Don't allow the `#[pointee]` attribute where it doesn't belong

Error if the `#[pointee]` attribute is applied to anything but generic type parameters.

Closes #128485
Related to #123430
2024-10-07 11:10:52 -07:00
clubby789
382365bfe3 Add test for issue 30867 2024-10-07 16:30:48 +00:00
clubby789
fa4f18be55 Add test for issue 30472 2024-10-07 16:30:48 +00:00
clubby789
b27c22d6b0 Add test for issue 28994 2024-10-07 16:30:47 +00:00
clubby789
ad7d41ce90 Test for issue 23600 2024-10-07 16:29:52 +00:00
Stuart Cook
dd4f062b07
Rollup merge of #128399 - mammothbane:master, r=Amanieu,tgross35
liballoc: introduce String, Vec const-slicing

This change `const`-qualifies many methods on `Vec` and `String`, notably `as_slice`, `as_str`, `len`. These changes are made behind the unstable feature flag `const_vec_string_slice`.

## Motivation
This is to support simultaneous variance over ownership and constness. I have an enum type that may contain either `String` or `&str`, and I want to produce a `&str` from it in a possibly-`const` context.

```rust
enum StrOrString<'s> {
    Str(&'s str),
    String(String),
}

impl<'s> StrOrString<'s> {
    const fn as_str(&self) -> &str {
        match self {
             // In a const-context, I really only expect to see this variant, but I can't switch the implementation
             // in some mode like #[cfg(const)] -- there has to be a single body
             Self::Str(s) => s,

             // so this is a problem, since it's not `const`
             Self::String(s) => s.as_str(),
        }
    }
}
```

Currently `String` and `Vec` don't support this, but can without functional changes. Similar logic applies for `len`, `capacity`, `is_empty`.

## Changes

The essential thing enabling this change is that `Unique::as_ptr` is `const`. This lets us convert `RawVec::ptr` -> `Vec::as_ptr` -> `Vec::as_slice` -> `String::as_str`.

I had to move the `Deref` implementations into `as_{str,slice}` because `Deref` isn't `#[const_trait]`, but I would expect this change to be invisible up to inlining. I moved the `DerefMut` implementations as well for uniformity.
2024-10-07 15:37:06 +11:00
Nathan Perry
d793766a61 liballoc: introduce String, Vec const-slicing
This change `const`-qualifies many methods on Vec and String, notably
`as_slice`, `as_str`, `len`. These changes are made behind the unstable
feature flag `const_vec_string_slice` with the following tracking issue:

https://github.com/rust-lang/rust/issues/129041
2024-10-06 19:58:35 -04:00
Brezak
aa4f16a6e7
Check that #[pointee] is applied only to generic arguments 2024-10-06 23:56:27 +02:00
bors
1b3b8e7b02 Auto merge of #128651 - folkertdev:naked-asm-macro-v2, r=Amanieu
add `naked_asm!` macro for use in `#[naked]` functions

tracking issue: https://github.com/rust-lang/rust/issues/90957

Adds the `core::arch::naked_asm` macro, to be used in `#[naked]` functions, but providing better error messages and a place to explain the restrictions on assembly in naked functions.

This PR does not yet require that the `naked_asm!` macro is used inside of `#[naked]` functions:

- the `asm!` macro can still be used in `#[naked]` functions currently, with the same restrictions and error messages as before.
- the `naked_asm!` macro can be used outside of `#[naked]` functions. It has not yet been decided whether that should be allowed long-term.

In this PR, the parsing code of `naked_asm!` now enforces the restrictions on assembly in naked functions, with the exception of checking that the `noreturn` option is specified. It also has not currently been decided if `noreturn` should be implicit or not.

This PR looks large because it touches a bunch of tests. The code changes are mostly straightforward I think: we now have 3 flavors of assembly macro, and that information must be propagated through the parsing code and error messages.

cc `@Lokathor`

r? `@Amanieu`
2024-10-06 21:51:18 +00:00
Folkert de Vries
5fc60d1e52 various fixes for naked_asm! implementation
- fix for divergence
- fix error message
- fix another cranelift test
- fix some cranelift things
- don't set the NORETURN option for naked asm
- fix use of naked_asm! in doc comment
- fix use of naked_asm! in run-make test
- use `span_bug` in unreachable branch
2024-10-06 19:00:09 +02:00
bors
8422e27b27 Auto merge of #129670 - est31:cfg_attr_crate_type_name_error, r=Urgau
Make deprecated_cfg_attr_crate_type_name a hard error

Turns the forward compatibility lint added by #83744 into a hard error, so now, while the `#![crate_name]` and `#![crate_type]` attributes are still allowed in raw form, they are now forbidden to be nested inside a `#![cfg_attr()]` attribute.

The following will now be an error:

```Rust
#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]
```

This code will continue working and is not deprecated:

```Rust
#![crate_name = "foobar"]
#![crate_type = "lib"]
```

The reasoning for this is explained in #83744: it allows us to not have to cfg-expand in order to determine the crate's type and name.

As of filing the PR, exactly two years have passed since #99784 has been merged, which has turned the lint's default warning level into an error, so there has been ample time to move off the now-forbidden syntax.

cc #91632 - tracking issue for the lint
2024-10-06 17:00:02 +00:00
Folkert de Vries
bc0a9543a3 more asm! -> naked_asm! in tests 2024-10-06 18:12:25 +02:00
Folkert de Vries
562ec5a6fb disallow asm! in #[naked] functions
also disallow the `noreturn` option, and infer `naked_asm!` as `!`
2024-10-06 18:12:25 +02:00
Folkert
1a9c1cbf36 use naked_asm! in feature-gate-naked_functions test 2024-10-06 18:12:25 +02:00
Folkert
47b42bef32 use naked_asm! in naked-function tests 2024-10-06 18:12:25 +02:00
Folkert
0aec55504c use naked_asm! in tests/ui/asm/naked-functions.rs 2024-10-06 18:12:25 +02:00
Matthias Krüger
11c41ff165
Rollup merge of #131312 - estebank:fn-in-pattern, r=compiler-errors
On function and method calls in patterns, link to the book

```
error: expected a pattern, found an expression
 --> f889.rs:3:13
  |
3 |     let (x, y.drop()) = (1, 2);
  |             ^^^^^^^^ not a pattern
  |
  = note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>

error[E0532]: expected a pattern, found a function call
 --> f889.rs:2:13
  |
2 |     let (x, drop(y)) = (1, 2);
  |             ^^^^ not a tuple struct or tuple variant
  |
  = note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```

Fix #97200.
2024-10-06 11:06:58 +02:00
Matthias Krüger
9aaebd481a
Rollup merge of #129392 - compiler-errors:raw-ref-op-doesnt-diverge-but-more, r=lcnr
Do not consider match/let/ref of place that evaluates to `!` to diverge, disallow coercions from them too

Fixes #117288.

This PR implements a heuristic which disables two things that are currently being performed on the HIR when we have **expressions that involve place-like expressions that point to `!`**. Specifically, it will (in certain cases explained below):

### (1.) Disable the `NeverToAny` coercion we implicitly insert for `!`.

Which fixes this inadvertent, sneaky unsoundness:

```
unsafe {
    let x: *const ! = &0 as *const u8 as *const !;
    let _: () = *x;
}
```

which is UB because currently rust emits an *implicit* NeverToAny coercion even though we really shouldn't be, since there's no read of the value pointed by `x`.

### (2.) Disable the logic which considers expression which evaluate to `!` to diverge, which affects the type returned by the containing block.

Which fixes this unsoundness:

```
fn make_up_a_value<T>() -> T {
    unsafe {
        let x: *const ! = &0 as *const u8 as *const !;
        let _ = *x;
    }
}
```

We disable these two operations **if** the expression is a place-like expression (locals, statics, field projections, index operations, and deref operations), and if the parent expression is either:
(1.) the LHS of an assignment
(2.) AddrOf
(3.) A match or let **unless** all of the *patterns consitute a read*, which is explained below:

And finally, a pattern currently is considered to constitute a read **unless** it is a wildcard, or an OR pattern. An OR pattern is considered to constitute a read if all of its subpatterns constitute a read, to remain as conservative as possible in cases like `_ | subpat` or `subpat | _`.

All other patterns are considered currently to constitute a read. Specifically, because `NeverToAny` is a coercion performed on a *value* and not a *place*, `Struct { .. }` on a `!` type must be a coercion currently, and we currently rely on this behavior to allow us to perform coercions like `let _: i32 = x;` where `x: !`.

This is already considered UB by [miri](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=daf3a2246433fe43fdc07d1389c276c9), but also means it does not affect the preexisting UB in this case:

```
let Struct { .. } = *never_ptr;
```

Even though it's likely up for debate since we're not actually reading any data out of the struct, it almost certainly causes inference changes which I do *NOT* want to fix in this PR.
2024-10-06 11:06:57 +02:00
bors
daebce4247 Auto merge of #130540 - veera-sivarajan:fix-87525, r=estebank
Add a Lint for Pointer to Integer Transmutes in Consts

Fixes #87525

This PR adds a MirLint for pointer to integer transmutes in const functions and associated consts. The implementation closely follows this comment: https://github.com/rust-lang/rust/pull/85769#issuecomment-880969112. More details about the implementation can be found in the comments.

Note: This could break some sound code as mentioned by RalfJung in https://github.com/rust-lang/rust/pull/85769#issuecomment-886491680:

> ... technically const-code could transmute/cast an int to a ptr and then transmute it back and that would be correct -- so the lint will deny some sound code. Does not seem terribly likely though.

References:
1. https://doc.rust-lang.org/std/mem/fn.transmute.html
2. https://doc.rust-lang.org/reference/items/associated-items.html#associated-constants
2024-10-06 02:39:23 +00:00
Esteban Küber
7f5548fa8b On function and method calls in patterns, link to the book
```
error: expected a pattern, found an expression
 --> f889.rs:3:13
  |
3 |     let (x, y.drop()) = (1, 2); //~ ERROR
  |             ^^^^^^^^ not a pattern
  |
  = note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>

error[E0532]: expected a pattern, found a function call
 --> f889.rs:2:13
  |
2 |     let (x, drop(y)) = (1, 2); //~ ERROR
  |             ^^^^ not a tuple struct or tuple variant
  |
  = note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```

Fix #97200.
2024-10-06 01:44:59 +00:00
Michael Goulet
e8d5eb2a2b Be far more strict about what we consider to be a read of never 2024-10-05 19:10:47 -04:00
Michael Goulet
515b93297f Document things a bit more carefully, also account for coercion in check_expr_has_type_or_error 2024-10-05 18:36:47 -04:00
Michael Goulet
73d49f8c69 Fix up tests 2024-10-05 18:36:47 -04:00
Michael Goulet
6371ef6e96 Evaluating place expr that is never read from does not diverge 2024-10-05 18:36:47 -04:00
Matthias Krüger
6a85c32f55
Rollup merge of #131299 - RalfJung:lang-item-track-caller, r=compiler-errors
fix typo in 'lang item with track_caller' message

Revival of https://github.com/rust-lang/rust/pull/124912
2024-10-05 19:07:55 +02:00
Matthias Krüger
8e31e98ff9
Rollup merge of #130555 - hegza:rv32e, r=workingjubilee
Initial support for riscv32{e|em|emc}_unknown_none_elf

We have a research prototype of an RV32EMC target and have been successfully running the e, em, emc programs on it. I'm hoping upstreaming this configuration would make the target maintenance slightly easier.

Configuration is based on the respective {i, im, imc} variants. As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE wrt. RVI is to reduce the number of integer registers to 16 (x0-x15), which also implies

- 2 callee saved registers instead of 12
- 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes

My initial presumption is that this will not impact how the target is defined for the compiler but only becomes relevant at the runtime level. I am willing to investigate, though.

EDIT: LLVM is now told about the presumed 32-bit stack alignment.

`@Disasm` `@romancardenas`
2024-10-05 19:07:53 +02:00
Ralf Jung
8faf3722ac fix typo in 'lang item with track_caller' message 2024-10-05 17:12:46 +02:00
bors
e561499e90 Auto merge of #131188 - Kobzol:remove-libstd-so-from-sysroot, r=onur-ozkan
Do not copy libstd dynamic library to sysroot

Since https://github.com/rust-lang/rust/pull/122362, rustc links statically to libstd.[so|dll]. Which means that the libstd.[so|dll] file no longer has to be in the rustc sysroot. However, we are currently still shipping this file, in every new release of Rust, for no reason, it's just wasted bytes.

This PR removes the dynamic library file from the built sysroot.

However, it is not yet performed on Windows, because stage0 incremental tests start failing there (see description of the issue [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Failing.20incr.20tests.20on.20Windows.20when.20std.2Edll.20is.20missing/near/474507064)).

This is an extended version of https://github.com/rust-lang/rust/pull/128986.
CC `@Zoxc`
2024-10-05 14:05:05 +00:00
Veera
ab8673501c Add a Lint for Pointer to Integer Transmutes in Consts 2024-10-05 12:48:02 +00:00
Matthias Krüger
cb5bb13ea9
Rollup merge of #131256 - RalfJung:f16-f128-const, r=ibraheemdev
move f16/f128 const fn under f16/f128 feature gate

The `*_const` features were added to work around https://github.com/rust-lang/rust/issues/129656, which should not be needed any more.
2024-10-05 13:15:58 +02:00
Henri Lunnikivi
346afc7017 Add UI test to verify invalid loads are not generated 2024-10-05 12:19:20 +03:00
Ralf Jung
0cd0f7ceef move f16/f128 const fn under f16/f128 feature gate 2024-10-05 10:13:18 +02:00
bors
5a4ee43c38 Auto merge of #129244 - cjgillot:opaque-hir, r=compiler-errors
Make opaque types regular HIR nodes

Having opaque types as HIR owner introduces all sorts of complications. This PR proposes to make them regular HIR nodes instead.

I haven't gone through all the test changes yet, so there may be a few surprises.

Many thanks to `@camelid` for the first draft.
Fixes https://github.com/rust-lang/rust/issues/129023

Fixes #129099
Fixes #125843
Fixes #119716
Fixes #121422
2024-10-05 06:19:35 +00:00
est31
00ed47b849 Make deprecated_cfg_attr_crate_type_name a hard error 2024-10-05 04:29:46 +02:00
Jubilee
08689af7b4
Rollup merge of #131273 - estebank:issue-131051, r=compiler-errors
Account for `impl Trait {` when `impl Trait for Type {` was intended

On editions where bare traits are never allowed, detect if the user has written `impl Trait` with no type, silence any dyn-compatibility errors, and provide a structured suggestion for the potentially missing type:

```
error[E0782]: trait objects must include the `dyn` keyword
  --> $DIR/missing-for-type-in-impl.rs:8:6
   |
LL | impl Foo<i64> {
   |      ^^^^^^^^
   |
help: add `dyn` keyword before this trait
   |
LL | impl dyn Foo<i64> {
   |      +++
help: you might have intended to implement this trait for a given type
   |
LL | impl Foo<i64> for /* Type */ {
   |               ++++++++++++++
```

CC #131051.
2024-10-04 19:19:27 -07:00
Jubilee
68de7d11a9
Rollup merge of #130633 - eholk:pin-reborrow-self, r=compiler-errors
Add support for reborrowing pinned method receivers

This builds on #130526 to add pinned reborrowing for method receivers. This enables the folllowing examples to work:

```rust
#![feature(pin_ergonomics)]
#![allow(incomplete_features)]

use std::pin::Pin;

pub struct Foo;

impl Foo {
    fn foo(self: Pin<&mut Self>) {
    }

    fn baz(self: Pin<&Self>) {
    }
}

pub fn bar(x: Pin<&mut Foo>) {
    x.foo();
    x.foo();

    x.baz(); // Pin<&mut Foo> is downgraded to Pin<&Foo>
}

pub fn baaz(x: Pin<&Foo>) {
    x.baz();
    x.baz();
}
```

This PR includes the original one, which is currently in the commit queue, but the only code changes are in the latest commit (d3c53aaa5c6fcb1018c58d229bc5d92202fa6880).

#130494

r? `@compiler-errors`
2024-10-04 19:19:24 -07:00
Jubilee
9510c7366d
Rollup merge of #130367 - compiler-errors:super-unconstrained, r=spastorino
Check elaborated projections from dyn don't mention unconstrained late bound lifetimes

Check that the projections that are *not* explicitly written but which we deduce from elaborating the principal of a `dyn` *also* do not reference unconstrained late-bound lifetimes, just like the ones that the user writes by hand.

That is to say, given:

```
trait Foo<T>: Bar<Assoc = T> {}

trait Bar {
    type Assoc;
}
```

The type `dyn for<'a> Foo<&'a T>` (basically) elaborates to `dyn for<'a> Foo<&'a T> + for<'a> Bar<Assoc = &'a T>`[^1]. However, the `Bar` projection predicate is not well-formed, since `'a` must show up in the trait's arguments to be referenced in the term of a projection. We must error in this situation[^well], or else `dyn for<'a> Foo<&'a T>` is unsound.

We already detect this for user-written projections during HIR->rustc_middle conversion, so this largely replicates that logic using the helper functions that were already conveniently defined.

---

I'm cratering this first to see the fallout; if it's minimal or zero, then let's land it as-is. If not, the way that this is implemented is very conducive to an FCW.

---

Fixes #130347

[^1]: We don't actually elaborate it like that in rustc; we only keep the principal trait ref `Foo<&'a T>` and the projection part of `Bar<Assoc = ...>`, but it's useful to be a bit verbose here for the purpose of explaining the issue.
[^well]: Well, we could also make `dyn for<'a> Foo<&'a T>` *not* implement `for<'a> Bar<Assoc = &'a T>`, but this is inconsistent with the case where the user writes `Assoc = ...` in the type itself, and it overly complicates the implementation of trait objects' built-in impls.
2024-10-04 19:19:22 -07:00
Jubilee
f09e5a785b
Rollup merge of #129517 - cjgillot:known-panic-array, r=pnkfelix
Compute array length from type for unconditional panic lint.

Fixes https://github.com/rust-lang/rust/issues/98444

The cases that involve slicing are harder, so https://github.com/rust-lang/rust/issues/38035 remains open.
2024-10-04 19:19:22 -07:00
Camille GILLOT
6b67c46a25 Compute array length from type for unconditional panic. 2024-10-05 00:19:26 +00:00
Camille GILLOT
6278e0f507 Promote crash tests to ui. 2024-10-04 23:44:29 +00:00
Camille GILLOT
d9f15faf3a Bless ui tests. 2024-10-04 23:38:41 +00:00
Esteban Küber
e057c43382 Account for impl Trait { when impl Trait for Type { was intended
On editions where bare traits are never allowed, detect if the user has
written `impl Trait` with no type, silence any dyn-compatibility errors,
and provide a structured suggestion for the potentially missing type:

```
error[E0782]: trait objects must include the `dyn` keyword
  --> $DIR/missing-for-type-in-impl.rs:8:6
   |
LL | impl Foo<i64> {
   |      ^^^^^^^^
   |
help: add `dyn` keyword before this trait
   |
LL | impl dyn Foo<i64> {
   |      +++
help: you might have intended to implement this trait for a given type
   |
LL | impl Foo<i64> for /* Type */ {
   |               ++++++++++++++
```
2024-10-04 22:59:03 +00:00
Michael Goulet
fd7ee484f9 Elaborate supertrait span correctly to label the error better 2024-10-04 17:15:28 -04:00
Michael Goulet
ae5f58d906 Check elaborated projections from dyn don't mention unconstrained late bound lifetimes 2024-10-04 17:15:28 -04:00
Jubilee
1462815098
Rollup merge of #131174 - madsmtm:target-info-sparc-abi, r=pnkfelix
Fix `target_abi` in `sparc-unknown-none-elf`

This was previously set to `target_abi = "elf"`, but `elf` is not used elsewhere as a target ABI (even though there's many targets that have it in their name), so I've removed it.

CC target maintainer ``@jonathanpallant,`` what do you think about this?
``@rustbot`` label O-SPARC
2024-10-04 14:11:36 -07:00
Jubilee
5a8fcab713
Rollup merge of #130518 - scottmcm:stabilize-controlflow-extra, r=dtolnay
Stabilize the `map`/`value` methods on `ControlFlow`

And fix the stability attribute on the `pub use` in `core::ops`.

libs-api in https://github.com/rust-lang/rust/issues/75744#issuecomment-2231214910 seemed reasonably happy with naming for these, so let's try for an FCP.

Summary:
```rust
impl<B, C> ControlFlow<B, C> {
    pub fn break_value(self) -> Option<B>;
    pub fn map_break<T>(self, f: impl FnOnce(B) -> T) -> ControlFlow<T, C>;
    pub fn continue_value(self) -> Option<C>;
    pub fn map_continue<T>(self, f: impl FnOnce(C) -> T) -> ControlFlow<B, T>;
}
```

Resolves #75744

``@rustbot`` label +needs-fcp +t-libs-api -t-libs

---

Aside, in case it keeps someone else from going down the same dead end: I looked at the `{break,continue}_value` methods and tried to make them `const` as part of this, but that's disallowed because of not having `const Drop`, so put it back to not even unstably-const.
2024-10-04 14:11:34 -07:00
Mads Marquart
f51d8e3276 Fix target_abi in sparc-unknown-none-elf
This was previously set to `target_abi = "elf"`, but `elf` is not used
elsewhere as a target ABI (even though there's many targets that have it
in their name).
2024-10-04 20:47:28 +02:00
bors
14f303bc14 Auto merge of #130157 - eduardosm:stabilize-const_float_classify, r=RalfJung
Stabilize `const_float_classify`

Tracking issue: https://github.com/rust-lang/rust/issues/72505

Also reverts https://github.com/rust-lang/rust/pull/114486

Closes https://github.com/rust-lang/rust/issues/72505

Stabilized const API:

```rust
impl f32 {
    pub const fn is_nan(self) -> bool;
    pub const fn is_infinite(self) -> bool;
    pub const fn is_finite(self) -> bool;
    pub const fn is_subnormal(self) -> bool;
    pub const fn is_normal(self) -> bool;
    pub const fn classify(self) -> FpCategory;
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
}

impl f64 {
    pub const fn is_nan(self) -> bool;
    pub const fn is_infinite(self) -> bool;
    pub const fn is_finite(self) -> bool;
    pub const fn is_subnormal(self) -> bool;
    pub const fn is_normal(self) -> bool;
    pub const fn classify(self) -> FpCategory;
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
}
```

cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
2024-10-04 18:03:16 +00:00
Guillaume Gomez
ba94a2ada1
Rollup merge of #131202 - Urgau:wide-ptrs-compiler, r=jieyouxu
Use wide pointers consistenly across the compiler

This PR replace every use of "fat pointer" for the more recent "wide pointer" terminology.

Since some time T-lang as preferred the "wide pointer" terminology, as can be seen on [the last RFCs](https://github.com/search?q=repo%3Arust-lang%2Frfcs+%22wide+pointer%22&type=code), on some [lints](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#ambiguous-wide-pointer-comparisons), but also in [the reference](https://doc.rust-lang.org/stable/reference/expressions/operator-expr.html?highlight=wide%20pointer#pointer-to-pointer-cast).

Currently we have a [mix of both](https://github.com/search?q=repo%3Arust-lang%2Frust+%22wide+pointer%22&type=code) (including in error messages), which isn't great, but with this PR no more.

r? `@jieyouxu` (feel free to re-roll)
2024-10-04 15:42:54 +02:00
Guillaume Gomez
2ceeeb159d
Rollup merge of #131034 - Urgau:cfg-true-false, r=nnethercote
Implement RFC3695 Allow boolean literals as cfg predicates

This PR implements https://github.com/rust-lang/rfcs/pull/3695: allow boolean literals as cfg predicates, i.e. `cfg(true)` and `cfg(false)`.

r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
2024-10-04 15:42:53 +02:00
Jakub Beránek
f59c8fffe3 Avoid dynamic linking to libstd in command-current-dir test 2024-10-04 15:34:31 +02:00
Urgau
018ba0528f Use wide pointers consistenly across the compiler 2024-10-04 14:06:48 +02:00
Urgau
a3ffa1eae5 Improve non-boolean literal error in cfg predicate 2024-10-04 09:09:20 +02:00
Urgau
62ef411631 Feature gate boolean lit support in cfg predicates 2024-10-04 09:09:20 +02:00
Matthias Krüger
28b64d8da6
Rollup merge of #131187 - Zalathar:bad-attr-ice, r=jieyouxu
Avoid ICE in coverage builds with bad `#[coverage(..)]` attributes

This code can sometimes witness malformed coverage attributes in builds that are going to fail, so use `span_delayed_bug` to avoid an inappropriate ICE in that case.

Fixes #127880.
2024-10-03 21:52:46 +02:00
Matthias Krüger
33b4947554
Rollup merge of #131112 - jswrenn:fix-130413, r=compiler-errors
TransmuteFrom: Gracefully handle unnormalized types and normalization errors

~~Refactor to share code between `TransmuteFrom`'s trait selection and error reporting code paths. Additionally normalizes the source and destination types, and gracefully handles normalization errors.~~

Fixes #130413

r​? `@compiler-errors`
2024-10-03 21:52:45 +02:00
Matthias Krüger
0d65f121a1
Rollup merge of #131024 - compiler-errors:deref-sugg, r=estebank
Don't give method suggestions when method probe fails due to bad implementation of `Deref`

If we have a bad `Deref` impl, we used to bail with `MethodError::NoMatch`, which makes the error reporting code think that there was no applicable method (and thus try to suggest importing something, even if it's in scope).

Suppress this error, which fixes #131003.
2024-10-03 21:52:44 +02:00
Matthias Krüger
aedf14bb0c
Rollup merge of #131163 - JakenHerman:master, r=Nadrieril
Add `get_line` confusable to `Stdin::read_line()`

This pull request resolves https://github.com/rust-lang/rust/issues/131091

---

I've updated tests for `tests/ui/attributes/rustc_confusables_std_cases` in order to verify this change is working as intended.

Before I submitted this pull request, I had a pull request to my local fork. If you're interested in seeing the conversation on that PR, go to https://github.com/JakenHerman/rust/pull/1.

---

**Testing**:
Run `./x.py test tests/ui/attributes/rustc_confusables_std_cases.rs`
2024-10-03 13:47:59 +02:00
Zalathar
8e382ba022 Avoid ICE in coverage builds with bad #[coverage(..)] attributes
This code can sometimes witness malformed coverage attributes in builds that
are going to fail, so use `span_delayed_bug` to avoid an inappropriate ICE in
that case.
2024-10-03 21:12:24 +10:00
Jubilee
b7c33e2f20
Rollup merge of #130725 - GrigorenkoPV:@-in-struct-patterns, r=Nadrieril
Parser: better error messages for `@` in struct patterns
2024-10-02 21:26:58 -07:00
Jaken Herman
4b48d72eaa Add get_line confusable to Stdin::read_line()
Add tests for addition of `#[rustc_confusables("get_line")]`
2024-10-02 23:19:26 -05:00
bors
18b1161ec9 Auto merge of #130821 - lcnr:nalgebra-hang-2, r=compiler-errors
add caching to most type folders, rm region uniquification

Fixes the new minimization of the hang in nalgebra and nalgebra itself :3

this is a bit iffy, especially the cache in `TypeRelating`. I believe all the caches are correct, but it definitely adds some non-local complexity in places. The first commit removes region uniquification, reintroducing the ICE from https://github.com/rust-lang/trait-system-refactor-initiative/issues/27. This does not affect coherence and I would like to fix this by introducing OR-region constraints

r? `@compiler-errors`
2024-10-02 19:21:44 +00:00
Matthias Krüger
b38f7ad9b1
Rollup merge of #131152 - fee1-dead-contrib:fxdiag, r=compiler-errors
Improve const traits diagnostics for new desugaring

r? project-const-traits
2024-10-02 17:10:47 +02:00
Matthias Krüger
2e0db79f0b
Rollup merge of #131150 - bvanjoi:issue-128327, r=chenyukang
only query `params_in_repr` if def kind is adt

Fixes #128327

`params_in_repr` was only stored in `encode_info_for_adt`, so we only query it when the def kind belongs to them.

9e3e517446/compiler/rustc_metadata/src/rmeta/encoder.rs (L1566-L1567)
2024-10-02 17:10:45 +02:00