Commit Graph

109 Commits

Author SHA1 Message Date
FedericoBruzzone
cef97bce7b Add TooGeneric variant to LayoutError and emit Unknown one
- `check-pass` test for a MRE of #135020
- fail test for #135138
- switch to `TooGeneric` for checking CMSE fn signatures
- switch to `TooGeneric` for compute `SizeSkeleton` (for transmute)
- fix broken tests
2025-01-27 00:37:34 +01:00
Matthias Krüger
9b40bd70de
Rollup merge of #135552 - amy-kwan:amy-kwan/reprc-struct-diagnostic-power-alignment, r=workingjubilee
[AIX] Lint on structs that have a different alignment in AIX's C ABI

This PR adds a linting diagnostic on AIX for repr(C) structs that are required to follow
the power alignment rule. A repr(C) struct needs to follow the power alignment rule if
the struct:
- Has a floating-point data type (greater than 4-bytes) as its first member, or
- The first member of the struct is an aggregate, whose recursively first member is a
   floating-point data type (greater than 4-bytes).

The power alignment rule for eligible structs is currently unimplemented, so a linting
diagnostic is produced when such a struct is encountered.
2025-01-23 09:49:19 +01:00
Amy Kwan
cd2ecc4b50 [AIX] Lint on structs that have a different alignment in AIX's C ABI 2025-01-22 12:06:16 -05:00
Michael Goulet
be56f10a69 Properly note when query stack is being cut off 2025-01-16 19:12:22 +00:00
Michael Goulet
b89a6e4932 Consider more erroneous layouts as LayoutError::ReferencesError to suppress spurious errors 2025-01-14 19:07:37 +00:00
The 8472
d89b6d5ac6 test that coercions still work under randomization 2025-01-10 02:22:57 +01:00
The 8472
56889dd826 exclude unsizable tail from randomization seed calculation 2025-01-10 02:22:57 +01:00
The 8472
d7fb729d39 adjust UI tests 2025-01-10 02:22:57 +01:00
The 8472
a75617c223 Foo<T> != Foo<U> under layout randomization
previously field ordering was using the same seed for all instances of Foo,
now we pass seed values through the layout tree so that not only
the struct itself affects layout but also its fields
2025-01-10 02:22:57 +01:00
John Kåre Alsaker
4bf85c25ec Try to write the panic message with a single write_all call 2025-01-01 15:58:29 +01:00
Zalathar
835fbcbcab Remove the -test suffix from normalize directives 2024-12-27 19:58:16 +11:00
Michael Goulet
c605c84be8 Stabilize async closures 2024-12-13 00:04:56 +00:00
León Orell Valerian Liehr
4d544d9443
Rollup merge of #134010 - RalfJung:promoted-type-error-ice, r=oli-obk
fix ICE on type error in promoted

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

Ensure that when we turn a type error into a "this promoted failed to evaluate" error, we do record this as something that may happen even in "infallible" promoteds.
2024-12-10 08:55:59 +01:00
Ralf Jung
ed8ee39930 fix ICE on type error in promoted 2024-12-09 15:17:26 +01:00
Esteban Küber
d860e5b088 Mention type parameter in more cases and don't suggest ~const bound already there 2024-12-07 21:37:13 +00:00
Esteban Küber
3f2a63a68b Use trait name instead of full constraint in suggestion message
```
help: consider restricting type parameter `T` with traits `Copy` and `Trait`
   |
LL | fn duplicate_custom<T: Copy + Trait>(t: S<T>) -> (S<T>, S<T>) {
   |                      ++++++++++++++
```

```
help: consider restricting type parameter `V` with trait `Copy`
   |
LL | fn index<'a, K, V: std::marker::Copy>(map: &'a HashMap<K, V>, k: K) -> &'a V {
   |                  +++++++++++++++++++
```
2024-12-07 21:29:58 +00:00
Esteban Küber
d13c34828e reword trait bound suggestion message to include the bounds 2024-12-07 21:26:20 +00:00
Esteban Küber
68253e14ee Don't suggest restricting bound with unstable traits on stable
On nightly, we mention the trait is unstable

```
error[E0277]: the trait bound `T: Unstable` is not satisfied
  --> $DIR/unstable-trait-suggestion.rs:13:9
   |
LL |     foo(t)
   |     --- ^ the trait `Unstable` is not implemented for `T`
   |     |
   |     required by a bound introduced by this call
   |
note: required by a bound in `foo`
  --> $DIR/unstable-trait-suggestion.rs:9:11
   |
LL | fn foo<T: Unstable>(_: T) {}
   |           ^^^^^^^^ required by this bound in `foo`
help: consider restricting type parameter `T` but it is an `unstable` trait
   |
LL | pub fn demo<T: Unstable>(t: T) {
   |              ++++++++++
```

On stable, we don't suggest the trait at all

```
error[E0277]: the trait bound `T: Unstable` is not satisfied
  --> $DIR/unstable-trait-suggestion.rs:13:9
   |
LL |     foo(t)
   |     --- ^ the trait `Unstable` is not implemented for `T`
   |     |
   |     required by a bound introduced by this call
   |
note: required by a bound in `foo`
  --> $DIR/unstable-trait-suggestion.rs:9:11
   |
LL | fn foo<T: Unstable>(_: T) {}
   |           ^^^^^^^^ required by this bound in `foo`
```
2024-12-07 21:10:44 +00:00
Eric Holk
72ce1ab42f
Stabilize noop_waker
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
2024-12-05 14:14:17 -08:00
Ralf Jung
a17294dc0f fix ICE when promoted has layout size overflow 2024-12-01 19:52:27 +01:00
许杰友 Jieyou Xu (Joe)
ae4fdf1445
Rollup merge of #133355 - chorman0773:spec-layout-tests, r=jieyouxu
Add language tests for aggregate types

This adds some tests for struct and union types, ensuring that they satisfy the rules for all structs and unions - namely that fields of structs do not overlap, fields are well-aligned, and the size of the entire.

The reference annotations used are from https://github.com/rust-lang/reference/pull/1654, though the rules tested here were FCPed in <https://github.com/rust-lang/reference/pull/1152>.
2024-11-23 20:50:16 +08:00
Connor Horman
8578ccc7ad
Remove #[cfg(test)] related stubs 2024-11-22 21:07:02 -05:00
Connor Horman
3d67fd4cf4
Add language tests for aggregate types 2024-11-22 19:32:02 -05:00
Michael Goulet
0465f71d60 Stop being so bail-y in candidate assembly 2024-11-21 01:35:34 +00:00
bors
7660aed73d Auto merge of #132173 - veluca93:abi_checks, r=RalfJung,compiler-errors
Emit warning when calling/declaring functions with unavailable vectors.

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 future-incompat warning 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](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187) for more discussion.

Part of #116558

r? RalfJung
2024-11-10 02:52:25 +00:00
Matthias Krüger
a4f323ce9c
Rollup merge of #132583 - mejrs:tuples, r=compiler-errors
Suggest creating unary tuples when types don't match a trait

When you want to have a variadic function, a common workaround to implement this is to create a trait and then implement that trait for various tuples. For example in `pyo3` there exists
```rust
/// Calls the object with only positional arguments.
pub fn call1(&self, args: impl IntoPy<Py<PyTuple>>) -> PyResult<&PyAny> {
   ...
}
```

with various impls like
```rust
impl<A: IntoPy<PyObject> IntoPy<Py<PyAny>> for (A,)
impl<A: IntoPy<PyObject, B: IntoPy<PyObject> IntoPy<Py<PyAny>> for (A, B)
... etc
```

This means that if you want to call the method with a single item you have to create a unary tuple, like `(x,)`, rather than just `x`.

This PR implements a suggestion to do that, if applicable.
2024-11-04 18:12:48 +01:00
mejrs
5a48fe2c20 Suggest creating unary tuples 2024-11-04 12:06:19 +01:00
dianne
d7d6238b23 use backticks instead of single quotes when reporting "use of unstable library feature"
This is consistent with all other diagnostics I could find containing
features and enables the use of `DiagSymbolList` for generalizing
diagnostics for unstable library features to multiple features.
2024-11-03 13:55:52 -08:00
Luca Versari
c8b76bcf58 Emit warning when calling/declaring functions with unavailable vectors.
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 future-incompat warning 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](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187)
for more discussion.

Part of #116558
2024-11-01 22:24:35 +01:00
Jubilee Young
083a362dd1 tests: Bless rustc_abi::Abi::Aggregate => ::Memory 2024-10-30 01:41:31 -07:00
Rémy Rakic
bd8477b562 Revert "Emit error when calling/declaring functions with unavailable vectors."
This reverts commit 5af56cac38.
2024-10-25 20:42:09 +00:00
bors
6faf0bd3e5 Auto merge of #127731 - veluca93:abi_checks, r=RalfJung
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 https://github.com/rust-lang/lang-team/issues/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](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187) for more discussion.

r? RalfJung

Part of https://github.com/rust-lang/rust/issues/116558
2024-10-25 15:17:47 +00:00
Luca Versari
5af56cac38 Emit error when calling/declaring functions with unavailable vectors.
On some architectures, vector types may have a different ABI when
relevant target features are enabled.

As discussed in https://github.com/rust-lang/lang-team/issues/235, this
turns out to very easily lead to unsound code.

This commit makes it an 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.
2024-10-25 08:46:40 +02:00
Jubilee Young
9f4c9155d4 compiler: Reject impossible reprs during enum layout 2024-10-20 02:12:58 -07:00
Jubilee Young
68d1fd9427 compiler: pre-move code for fixing enum layout ICEs 2024-10-20 02:09:22 -07:00
Michael Goulet
17eca60c24 Dont ICE when encountering post-mono layout cycle error 2024-10-08 16:46:16 -04:00
Jubilee Young
325af25c94 TL note: current means target 2024-09-20 10:02:14 -07:00
Lukas Markeffsky
20d2414925 get rid of an old hack
For structs that cannot be unsized, the layout algorithm sometimes moves
unsized fields to the end of the struct, which circumvented the error
for unexpected unsized fields and returned an unsized layout anyway.

This commit makes it so that the unexpected unsized error is always
returned for structs that cannot be unsized, allowing us to remove an
old hack and fixing some old ICE.
2024-09-17 00:09:21 +02:00
Lukas Markeffsky
697450151c layout computation: eagerly error for unexpected unsized fields 2024-09-16 15:53:21 +02:00
Scott McMurray
d2309c2a9d Ban non-array SIMD 2024-09-09 19:39:43 -07:00
Matthias Krüger
130d15e23e
Rollup merge of #126152 - RalfJung:size_of_val_raw, r=saethlin
size_of_val_raw: for length 0 this is safe to call

For motivation, see https://github.com/rust-lang/unsafe-code-guidelines/issues/465, specifically around [here](https://github.com/rust-lang/unsafe-code-guidelines/issues/465#issuecomment-2136401114).
Cc `@rust-lang/opsem`
2024-07-24 18:00:35 +02:00
Zalathar
9aaa0c5867 Always use a colon in //@ normalize-*: headers 2024-07-11 12:23:44 +10:00
Ralf Jung
287b66b0b5 size_of_val_raw: for length 0 this is safe to call 2024-07-10 18:01:06 +02:00
bors
bda221a0eb Auto merge of #125740 - RalfJung:transmute-size-check, r=oli-obk
transmute size check: properly account for alignment

Fixes another place where ZST alignment was ignored when checking whether something is a newtype. I wonder how many more of these there are...

Fixes https://github.com/rust-lang/rust/issues/101084
2024-06-25 07:21:17 +00:00
Ralf Jung
9f0c7f00d1 transmute size check: properly account for alignment 2024-05-30 10:06:28 +02:00
Oli Scherer
a04ac26a9d Allow type_of to return partially non-error types if the type was already tainted 2024-05-28 11:55:20 +00:00
Matthias Krüger
8859631b40
Rollup merge of #124057 - gurry:124031-ice-layout-errored, r=compiler-errors
Fix ICE when ADT tail has type error

Fixes #124031
2024-04-23 06:24:55 +02:00
Markus Reiter
33e68aadc9
Stabilize generic NonZero. 2024-04-22 18:48:47 +02:00
Gurinder Singh
06cd79bb5b Fix ICE when ADT tail has type error 2024-04-22 09:12:36 +05:30
Matthias Krüger
7d9e1067fd add test for ICE: Unexpected unsized type tail: &ReStatic [u8] #122488
Fixes https://github.com/rust-lang/rust/issues/122488
2024-04-06 23:34:46 +02:00