1
Fork 0
Commit graph

41838 commits

Author SHA1 Message Date
Matthias Krüger
1868c8f66f
Rollup merge of #133424 - Nadrieril:guard-patterns-parsing, r=fee1-dead
Parse guard patterns

This implements the parsing of [RFC3637 Guard Patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see also [tracking issue](https://github.com/rust-lang/rust/issues/129967)). This PR is extracted from https://github.com/rust-lang/rust/pull/129996 with minor modifications.

cc `@max-niederman`
2024-12-08 17:18:50 +01:00
Matthias Krüger
d4b5345248
Rollup merge of #133992 - compiler-errors:walk-fully, r=jieyouxu
Actually walk into lifetimes and attrs in `EarlyContextAndPass`

Visitors that don't also call `walk_*` are kinda a footgun...

I believe all the other early lint functions walk into their types correctly at this point.
2024-12-08 14:28:26 +01:00
Matthias Krüger
0d26662fd3
Rollup merge of #133861 - shamb0:refactor_InterpCx_allocate_str, r=RalfJung
Add allocate_bytes and refactor allocate_str in InterpCx for raw byte…

Fixes https://github.com/rust-lang/miri/issues/4025

This PR introduces a new `allocate_bytes` function in InterpCx and refactors `allocate_str` to use it internally. This change improves memory allocation handling in the interpreter by:

1. Adding `allocate_bytes`:
   - Direct byte slice allocation support
   - Handles both mutable and immutable allocations
   - Maintains proper memory alignment and deduplication

2. Refactoring `allocate_str`:
   - Now uses `allocate_bytes` internally
   - Adds string-specific metadata handling
   - Preserves existing string allocation behavior

This is part 1 of the planned changes to improve timezone string handling in Miri. A follow-up PR will update Miri's timezone logic to use this new allocation mechanism.

Related: https://github.com/rust-lang/miri/pull/4069
2024-12-08 14:28:24 +01:00
Matthias Krüger
a369714a29
Rollup merge of #133767 - estebank:multiple-dep-version-tests, r=Nadrieril
Add more info on type/trait mismatches for different crate versions

When encountering a type or trait mismatch for two types coming from two different crates with the same name, detect if it is either mixing two types/traits from the same crate on different versions:

```
error[E0308]: mismatched types
  --> replaced
   |
LL |     do_something_type(Type);
   |     ----------------- ^^^^ expected `dependency::Type`, found `dep_2_reexport::Type`
   |     |
   |     arguments to this function are incorrect
   |
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
  --> replaced
   |
LL | pub struct Type(pub i32);
   | ^^^^^^^^^^^^^^^ this is the expected type `dependency::Type`
   |
  ::: replaced
   |
LL | pub struct Type;
   | ^^^^^^^^^^^^^^^ this is the found type `dep_2_reexport::Type`
   |
  ::: replaced
   |
LL | extern crate dep_2_reexport;
   | ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
   | ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
   = help: you can use `cargo tree` to explore your dependency tree
note: function defined here
  --> replaced
   |
LL | pub fn do_something_type(_: Type) {}
   |        ^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> replaced
   |
LL |     do_something_trait(Box::new(Type) as Box<dyn Trait2>);
   |     ------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected trait `dependency::Trait2`, found trait `dep_2_reexport::Trait2`
   |     |
   |     arguments to this function are incorrect
   |
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
  --> replaced
   |
LL | pub trait Trait2 {}
   | ^^^^^^^^^^^^^^^^ this is the expected trait `dependency::Trait2`
   |
  ::: replaced
   |
LL | pub trait Trait2 {}
   | ^^^^^^^^^^^^^^^^ this is the found trait `dep_2_reexport::Trait2`
   |
  ::: replaced
   |
LL | extern crate dep_2_reexport;
   | ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
   | ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
   = help: you can use `cargo tree` to explore your dependency tree
note: function defined here
  --> replaced
   |
LL | pub fn do_something_trait(_: Box<dyn Trait2>) {}
   |        ^^^^^^^^^^^^^^^^^^
```

or if it is different crates that were renamed to the same name:

```
error[E0308]: mismatched types
  --> $DIR/type-mismatch-same-crate-name.rs:21:20
   |
LL |         a::try_foo(foo2);
   |         ---------- ^^^^ expected `main:🅰️:Foo`, found a different `main:🅰️:Foo`
   |         |
   |         arguments to this function are incorrect
   |
note: two types coming from two different crates are different types even if they look the same
  --> $DIR/auxiliary/crate_a2.rs:1:1
   |
LL | pub struct Foo;
   | ^^^^^^^^^^^^^^ this is the found type `crate_a2::Foo`
   |
  ::: $DIR/auxiliary/crate_a1.rs:1:1
   |
LL | pub struct Foo;
   | ^^^^^^^^^^^^^^ this is the expected type `crate_a1::Foo`
   |
  ::: $DIR/type-mismatch-same-crate-name.rs:13:17
   |
LL |     let foo2 = {extern crate crate_a2 as a; a::Foo};
   |                 --------------------------- one type comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL |         extern crate crate_a1 as a;
   |         --------------------------- one type comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
  --> $DIR/auxiliary/crate_a1.rs:10:8
   |
LL | pub fn try_foo(x: Foo){}
   |        ^^^^^^^

error[E0308]: mismatched types
  --> $DIR/type-mismatch-same-crate-name.rs:27:20
   |
LL |         a::try_bar(bar2);
   |         ---------- ^^^^ expected trait `main:🅰️:Bar`, found a different trait `main:🅰️:Bar`
   |         |
   |         arguments to this function are incorrect
   |
note: two types coming from two different crates are different types even if they look the same
  --> $DIR/auxiliary/crate_a2.rs:3:1
   |
LL | pub trait Bar {}
   | ^^^^^^^^^^^^^ this is the found trait `crate_a2::Bar`
   |
  ::: $DIR/auxiliary/crate_a1.rs:3:1
   |
LL | pub trait Bar {}
   | ^^^^^^^^^^^^^ this is the expected trait `crate_a1::Bar`
   |
  ::: $DIR/type-mismatch-same-crate-name.rs:13:17
   |
LL |     let foo2 = {extern crate crate_a2 as a; a::Foo};
   |                 --------------------------- one trait comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL |         extern crate crate_a1 as a;
   |         --------------------------- one trait comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
  --> $DIR/auxiliary/crate_a1.rs:11:8
   |
LL | pub fn try_bar(x: Box<Bar>){}
   |        ^^^^^^^
```

This new output unifies the E0308 errors detail with the pre-existing E0277 errors, and better differentiates the "`extern crate` renamed" and "same crate, different versions" cases.
2024-12-08 14:28:24 +01:00
Matthias Krüger
703bb98230
Rollup merge of #131669 - niacdoial:linting-ptrdyn-ffi, r=workingjubilee
lint: change help for pointers to dyn types in FFI

### Context
while playing around, I encountered the warning for dyn types in `extern "C"` functions, but even after that I assumed that a (rust) raw pointer could be interpreted in C ('s ABI) as a `void *`... to be fair part of why I ignored the warning is because I wanted to poke at the generated assembly, not make useful code.

### Example

```rust
extern "C"
fn caller(callee: *const dyn Fn(i32)->i32){
    // -- snip --
}
```

old warning:
```
warning: `extern` fn uses type `dyn Fn(i32) -> i32`, which is not FFI-safe
 --> file/name.rs:42:19
   |
42 | fn caller(callee: *const dyn Fn(i32)->i32) {
   |                   ^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
   |
  = note: trait objects have no C equivalent
  = note: `#[warn(improper_ctypes_definitions)]` on by default
  ```

new warning:
```
warning: `extern` fn uses type `dyn Fn(i32) -> i32`, which is not FFI-safe
 --> file/name.rs:42:19
   |
42 | fn caller(callee: *const dyn Fn(i32)->i32) -> (){
   |                   ^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe
   |
  = note: this pointer to an unsized type contains metadata, which makes it incompatible with a C pointer
  = note: `#[warn(improper_ctypes_definitions)]` on by default
```
2024-12-08 14:28:22 +01:00
Esteban Küber
25ad0478cb Tweak wording 2024-12-07 22:18:51 +00:00
Esteban Küber
b466405890 Do not talk about "trait <Foo = Bar>"
Pass in an appropriate `Option<DefId>` in more cases from hir ty lowering.
2024-12-07 21:37:15 +00:00
Esteban Küber
cb4db0a6c6 Account for impl Trait in "add bound" suggestion message 2024-12-07 21:37:15 +00: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
568b0ac624 Add test for lack of suggestion in stable
This test will break when `Step` gets stabilized, but punt until then.
2024-12-07 21:26:23 +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
Esteban Küber
16bf7223ea Add more info on type/trait mismatches for different crate versions
When encountering a type or trait mismatch for two types coming from two different crates with the same name, detect if it is either mixing two types/traits from the same crate on different versions:

```
error[E0308]: mismatched types
  --> replaced
   |
LL |     do_something_type(Type);
   |     ----------------- ^^^^ expected `dependency::Type`, found `dep_2_reexport::Type`
   |     |
   |     arguments to this function are incorrect
   |
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
  --> replaced
   |
LL | pub struct Type(pub i32);
   | ^^^^^^^^^^^^^^^ this is the expected type `dependency::Type`
   |
  ::: replaced
   |
LL | pub struct Type;
   | ^^^^^^^^^^^^^^^ this is the found type `dep_2_reexport::Type`
   |
  ::: replaced
   |
LL | extern crate dep_2_reexport;
   | ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
   | ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
   = help: you can use `cargo tree` to explore your dependency tree
note: function defined here
  --> replaced
   |
LL | pub fn do_something_type(_: Type) {}
   |        ^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> replaced
   |
LL |     do_something_trait(Box::new(Type) as Box<dyn Trait2>);
   |     ------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected trait `dependency::Trait2`, found trait `dep_2_reexport::Trait2`
   |     |
   |     arguments to this function are incorrect
   |
note: two different versions of crate `dependency` are being used; two types coming from two different versions of the same crate are different types even if they look the same
  --> replaced
   |
LL | pub trait Trait2 {}
   | ^^^^^^^^^^^^^^^^ this is the expected trait `dependency::Trait2`
   |
  ::: replaced
   |
LL | pub trait Trait2 {}
   | ^^^^^^^^^^^^^^^^ this is the found trait `dep_2_reexport::Trait2`
   |
  ::: replaced
   |
LL | extern crate dep_2_reexport;
   | ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
LL | extern crate dependency;
   | ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
   = help: you can use `cargo tree` to explore your dependency tree
note: function defined here
  --> replaced
   |
LL | pub fn do_something_trait(_: Box<dyn Trait2>) {}
   |        ^^^^^^^^^^^^^^^^^^
```

or if it is different crates that were renamed to the same name:

```
error[E0308]: mismatched types
  --> $DIR/type-mismatch-same-crate-name.rs:21:20
   |
LL |         a::try_foo(foo2);
   |         ---------- ^^^^ expected `main:🅰️:Foo`, found a different `main:🅰️:Foo`
   |         |
   |         arguments to this function are incorrect
   |
note: two types coming from two different crates are different types even if they look the same
  --> $DIR/auxiliary/crate_a2.rs:1:1
   |
LL | pub struct Foo;
   | ^^^^^^^^^^^^^^ this is the found type `crate_a2::Foo`
   |
  ::: $DIR/auxiliary/crate_a1.rs:1:1
   |
LL | pub struct Foo;
   | ^^^^^^^^^^^^^^ this is the expected type `crate_a1::Foo`
   |
  ::: $DIR/type-mismatch-same-crate-name.rs:13:17
   |
LL |     let foo2 = {extern crate crate_a2 as a; a::Foo};
   |                 --------------------------- one type comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL |         extern crate crate_a1 as a;
   |         --------------------------- one type comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
  --> $DIR/auxiliary/crate_a1.rs:10:8
   |
LL | pub fn try_foo(x: Foo){}
   |        ^^^^^^^

error[E0308]: mismatched types
  --> $DIR/type-mismatch-same-crate-name.rs:27:20
   |
LL |         a::try_bar(bar2);
   |         ---------- ^^^^ expected trait `main:🅰️:Bar`, found a different trait `main:🅰️:Bar`
   |         |
   |         arguments to this function are incorrect
   |
note: two types coming from two different crates are different types even if they look the same
  --> $DIR/auxiliary/crate_a2.rs:3:1
   |
LL | pub trait Bar {}
   | ^^^^^^^^^^^^^ this is the found trait `crate_a2::Bar`
   |
  ::: $DIR/auxiliary/crate_a1.rs:3:1
   |
LL | pub trait Bar {}
   | ^^^^^^^^^^^^^ this is the expected trait `crate_a1::Bar`
   |
  ::: $DIR/type-mismatch-same-crate-name.rs:13:17
   |
LL |     let foo2 = {extern crate crate_a2 as a; a::Foo};
   |                 --------------------------- one trait comes from crate `crate_a2` is used here, which is renamed locally to `a`
...
LL |         extern crate crate_a1 as a;
   |         --------------------------- one trait comes from crate `crate_a1` is used here, which is renamed locally to `a`
note: function defined here
  --> $DIR/auxiliary/crate_a1.rs:11:8
   |
LL | pub fn try_bar(x: Box<Bar>){}
   |        ^^^^^^^
```

This new output unifies the E0308 errors detail with the pre-existing E0277 errors, and better differentiates the "`extern crate` renamed" and "same crate, different versions" cases.
2024-12-07 18:18:08 +00:00
Nadrieril
2459dbb4ba Address review comments 2024-12-07 13:37:35 +01:00
shamb0
9b07e75055 Add allocate_bytes and refactor allocate_str in InterpCx for raw byte allocation
Signed-off-by: shamb0 <r.raajey@gmail.com>
2024-12-07 16:36:17 +05:30
bors
9c707a8b76 Auto merge of #133978 - matthiaskrgr:rollup-6gh1iho, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #130209 (Stabilize `std::io::ErrorKind::CrossesDevices`)
 - #130254 (Stabilize `std::io::ErrorKind::QuotaExceeded`)
 - #132187 (Add Extend impls for tuples of arity 1 through 12)
 - #133875 (handle `--json-output` properly)
 - #133934 (Do not implement unsafe auto traits for types with unsafe fields)
 - #133954 (Hide errors whose suggestions would contain error constants or types)
 - #133960 (rustdoc: remove eq for clean::Attributes)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-12-07 09:38:00 +00:00
bors
cdb89d6b15 Auto merge of #133897 - oli-obk:push-lsxrqtqqwmpt, r=jieyouxu
Remove a lit_to_const call

We have so many special cases of `match expr.kind { Lit() => {}, Unary(Neg, Lit()) => {} }`... I'm trying to figure out how to get these all unified, but outright removing some is good, too. So let's try it.

Tho we don't have many `const {}` blocks in the perf test suite... But I also don't know how common `const { 42 }` blocks are, I'd expect these to occur mostly from macros (like `thread_local!`)
2024-12-07 06:56:50 +00:00
Michael Goulet
db9e3681f9 Actually walk into lifetimes and attrs in EarlyContextAndPass 2024-12-07 02:08:40 +00:00
Ben Kimock
711c8cc690 Remove polymorphization 2024-12-06 16:42:09 -05:00
Jubilee Young
02072fd83a compiler: Tighten up ImproperCTypesLayer recursion 2024-12-06 22:23:13 +01:00
niacdoial
8b6289f6ae lint ImproperCTypes: message tweaks and refactoring from code review 2024-12-06 22:23:13 +01:00
niacdoial
9b59dd8178 lint ImproperCTypes: confirm that Box<FfiSafeType> and Option<Box<FfiSafeType>> are FFI-safe in function declarations too 2024-12-06 22:23:13 +01:00
niacdoial
d857bc8fbb lint: polish code from the last few commits 2024-12-06 22:23:13 +01:00
niacdoial
7962a2de3a lint: fix ImproperCTypes edge case for unsized structs due to foreign types 2024-12-06 22:23:13 +01:00
niacdoial
1d52131043 lint: rework some ImproperCTypes messages (especially around indirections to !Sized) 2024-12-06 22:23:13 +01:00
niacdoial
f021d99cc8 lint: revamp ImproperCTypes diagnostic architecture for nested notes and help messages 2024-12-06 22:23:05 +01:00
Matthias Krüger
5d3a96346d
Rollup merge of #133954 - oli-obk:push-lxrmszqzszzu, r=jieyouxu
Hide errors whose suggestions would contain error constants or types

best reviewed commit-by-commit.

This is work towards cleaning up everything around `lit_to_const` and its mir equivalent.

fixes #123809
2024-12-06 21:21:07 +01:00
Matthias Krüger
6457761f80
Rollup merge of #133934 - jswrenn:unsafe-fields-auto-traits, r=compiler-errors
Do not implement unsafe auto traits for types with unsafe fields

If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Consequently, auto implementations of unsafe auto traits should not be generated for types with unsafe fields.

Tracking: #132922

r? `@compiler-errors`
2024-12-06 21:21:07 +01:00
bors
cdeddae4f6 Auto merge of #133956 - bjorn3:sync_cg_clif-2024-12-06, r=bjorn3
Sync cg clif 2024 12 06

The main highlights this time are a Cranelift update disabling the clif ir verifier by default for better performance.

r? `@ghost`

`@rustbot` label +A-codegen +A-cranelift +T-compiler
2024-12-06 15:49:11 +00:00
bjorn3
b3d837afe1 Merge commit '57845a397e' into sync_cg_clif-2024-12-06 2024-12-06 12:10:30 +00:00
Oli Scherer
060cecba1a Hide errors whose suggestions would contain error constants or types 2024-12-06 10:50:20 +00:00
Oli Scherer
cb72b9bb37 Silence follow-up errors from lit_to_const 2024-12-06 10:50:20 +00:00
Matthias Krüger
875df6c59c
Rollup merge of #133931 - bjorn3:even_stricter_fn_abi_sanity_checking, r=nnethercote
Only allow PassMode::Direct for aggregates on wasm when using the C ABI

For the Rust ABI we don't have any ABI compat reasons to allow PassMode::Direct for aggregates.
2024-12-06 09:27:41 +01:00
Matthias Krüger
576176d8b7
Rollup merge of #133211 - Strophox:miri-correct-state-update-ffi, r=RalfJung
Extend Miri to correctly pass mutable pointers through FFI

Based off of https://github.com/rust-lang/rust/pull/129684, this PR further extends Miri to execute native calls that make use of pointers to *mutable* memory.
We adapt Miri's bookkeeping of internal state upon any FFI call that gives external code permission to mutate memory.

Native code may now possibly write and therefore initialize and change the pointer provenance of bytes it has access to: Such memory is assumed to be *initialized* afterwards and bytes are given *arbitrary (wildcard) provenance*. This enables programs that correctly use mutating FFI calls to run Miri without errors, at the cost of possibly missing Undefined Behaviour caused by incorrect usage of mutating FFI.

> <details>
>
> <summary> Simple example </summary>
>
> ```rust
> extern "C" {
>   fn init_int(ptr: *mut i32);
> }
>
> fn main() {
>   let mut x = std::mem::MaybeUninit::<i32>::uninit();
>   let x = unsafe {
>     init_int(x.as_mut_ptr());
>     x.assume_init()
>   };
>
>   println!("C initialized my memory to: {x}");
> }
> ```
> ```c
> void init_int(int *ptr) {
>   *ptr = 42;
> }
> ```
> should now show `C initialized my memory to: 42`.
>
> </details>

r? ``@RalfJung``
2024-12-06 09:27:39 +01:00
Matthias Krüger
820ddaf67a
Rollup merge of #130777 - azhogin:azhogin/reg-struct-return, r=workingjubilee
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)

Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.

- Tracking issue: https://github.com/rust-lang/rust/issues/116973
2024-12-06 09:27:38 +01:00
bjorn3
8922d30a87 Only allow PassMode::Direct for aggregates on wasm when using the C ABI
For the Rust ABI we don't have any ABI compat reasons to allow
PassMode::Direct for aggregates.
2024-12-06 08:26:33 +00:00
bors
acf48426b6 Auto merge of #133559 - compiler-errors:structurally-resolve-adjust-for-branch, r=lcnr
Structurally resolve in `adjust_for_branches`

r? lcnr
2024-12-06 04:55:35 +00:00
Jack Wrenn
a122dde217 do not implement unsafe auto traits for types with unsafe fields
If a type has unsafe fields, its safety invariants are not simply
the conjunction of its field types' safety invariants. Consequently,
it's invalid to reason about the safety properties of these types
in a purely structural manner — i.e., the manner in which `auto`
traits are implemented.

Makes progress towards #132922.
2024-12-05 23:52:21 +00:00
Guillaume Gomez
5dc05a8d01
Rollup merge of #133936 - oli-obk:push-qmvqsmwqrtqr, r=lqd
Avoid fetching the anon const hir node that is already available
2024-12-05 23:47:13 +01:00
Guillaume Gomez
e941e73368
Rollup merge of #133607 - WaffleLapkin:tail-call-checks, r=compiler-errors
implement checks for tail calls

Quoting the [RFC draft](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md):

> The argument to become is a function (or method) call, that exactly matches the function signature and calling convention of the callee. The intent is to ensure a matching ABI. Note that lifetimes may differ as long as they pass borrow checking, see [below](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md#return-type-coercion) for specifics on the return type.

> Tail calling closures and tail calling from closures is not allowed. This is due to the high implementation effort, see below, this restriction can be lifted by a future RFC.

> Invocations of operators were considered as valid targets but were rejected on grounds of being too error-prone. In any case, these can still be called as methods.

> Tail calling [variadic functions](https://doc.rust-lang.org/beta/unstable-book/language-features/c-variadic.html) and tail calling from variadic functions is not allowed. As support for variadic function is stabilized on a per target level, support for tail-calls regarding variadic functions would need to follow a similar approach. To avoid this complexity and to minimize implementation effort for backends, this interaction is currently not allowed but support can be added with a future RFC.

-----

The checks are implemented as a query, similarly to `check_unsafety`.

The code is cherry-picked straight out of #112657 which was written more than a year ago, so I expect we might need to change some things ^^"
2024-12-05 23:47:10 +01:00
Strophox
712ceaba35 extend Miri to correctly pass mutable pointers through FFI
Co-authored-by: Ralf Jung <post@ralfj.de>
2024-12-05 22:41:07 +01:00
Oli Scherer
44019ee330 Avoid looking at HIR for inline const pattern literals 2024-12-05 16:32:31 +00:00
Jacob Pratt
5dd102e2f8
Rollup merge of #133867 - taiki-e:platform-support, r=Noratrieb
Fix "std" support status of some tier 3 targets

https://github.com/rust-lang/rust/pull/127265 marked targets with empty "std" support status as no-std targets in target-spec metadata:

> * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build

However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.)

https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3

> The `std` column in the table below has the following meanings:
>
> * ✓ indicates the full standard library is available.
> * \* indicates the target only supports [`no_std`] development.
> * ? indicates the standard library support is unknown or a work-in-progress.
>
> [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html

This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata.

The new status is set based on the following criteria:

- Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl)
  - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl f3068b66e0), so I included them in the group below that means “work in progress” rather than in this group.
- Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available.
- Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported.

r? Noratrieb
cc ``@harmou01``
2024-12-05 05:50:52 -05:00
Jacob Pratt
b5a7f41a87
Rollup merge of #127565 - esp-rs:xtensa-vaargs, r=workingjubilee
Teach rustc about the Xtensa VaListImpl

Following on from the target Xtensa target PRs (https://github.com/rust-lang/rust/pull/125141, https://github.com/rust-lang/rust/pull/126380), this PR teaches rustc about the structure of the VA list on the Xtensa arch, as well as adding the required lowering to be able to actually use it.
2024-12-05 05:50:50 -05:00
Oli Scherer
62c7ce44de Avoid fetching the anon const hir node that is already available 2024-12-05 09:02:16 +00:00
bors
0e98766a54 Auto merge of #133893 - fmease:rollup-11pi6fg, r=fmease
Rollup of 10 pull requests

Successful merges:

 - #118833 (Add lint against function pointer comparisons)
 - #122161 (Fix suggestion when shorthand `self` has erroneous type)
 - #133233 (Add context to "const in pattern" errors)
 - #133761 (Update books)
 - #133843 (Do not emit empty suggestion)
 - #133863 (Rename `core_pattern_type` and `core_pattern_types` lib feature  gates to `pattern_type_macro`)
 - #133872 (No need to create placeholders for GAT args in confirm_object_candidate)
 - #133874 (`fn_sig_for_fn_abi` should return a `ty::FnSig`, no need for a binder)
 - #133890 (Add a new test ui/incoherent-inherent-impls/no-other-unrelated-errors to check E0116 does not cause unrelated errors)
 - #133892 (Revert #133817)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-12-05 07:08:49 +00:00
León Orell Valerian Liehr
4f99d6c95e
Rollup merge of #133874 - compiler-errors:fn-sig-binder, r=oli-obk
`fn_sig_for_fn_abi` should return a `ty::FnSig`, no need for a binder

r? oli-obk

Split out of #133122
2024-12-05 07:29:58 +01:00
León Orell Valerian Liehr
3a01e40d32
Rollup merge of #133872 - compiler-errors:simplify-gat-check, r=oli-obk
No need to create placeholders for GAT args in confirm_object_candidate

We no longer need this logic to add placeholders for GAT args since with the removal of the `gat_extended` feature gate (https://github.com/rust-lang/rust/pull/133768) we no longer allow GATs in dyn trait anyways.

r? oli-obk
2024-12-05 07:29:57 +01:00
León Orell Valerian Liehr
ab16eeba5c
Rollup merge of #133843 - estebank:empty-semi-sugg, r=jieyouxu
Do not emit empty suggestion

The `println!();` statement's span doesn't include the `;`, and the modified suggestions where trying to get the `;` by getting the differenece between the statement's and the expression's spans, which was an empty suggestion.

Fix #133833, fix #133834.
2024-12-05 07:29:56 +01:00