Commit graph

34755 commits

Author SHA1 Message Date
bors 385fa9d845 Auto merge of #123097 - oli-obk:perf_experiment, r=petrochenkov
Try using a `dyn Debug` trait object instead of a closure

These closures were introduced in https://github.com/rust-lang/rust/pull/93098

let's see if we can't use fmt::Arguments instead

cc `@Aaron1011`
2024-04-04 20:52:52 +00:00
bors a4b11c8e60 Auto merge of #121394 - oli-obk:define_opaque_types, r=compiler-errors
some smaller DefiningOpaqueTypes::No -> Yes switches

r? `@compiler-errors`

These are some easy cases, so let's get them out of the way first.
I added tests exercising the specialization code paths that I believe weren't tested so far.

follow-up to https://github.com/rust-lang/rust/pull/117348
2024-04-04 17:42:07 +00:00
Oli Scherer ede0556ab5 Effects are boolean consts and don't contain opaque types 2024-04-04 15:43:14 +00:00
Oli Scherer 0183d92df0 Allow defining opaque types when checking const equality bounds 2024-04-04 15:43:02 +00:00
bors 0fd571286e Auto merge of #123377 - oli-obk:private_projection, r=compiler-errors
Only inspect user-written predicates for privacy concerns

fixes #123288

Previously we looked at the elaborated predicates, which, due to adding various bounds on fields, end up requiring trivially true bounds. But these bounds can contain private types, which the privacy visitor then found and errored about.
2024-04-04 15:39:00 +00:00
Oli Scherer 8e226e092e Add some regression tests for opaque types and const generics 2024-04-04 15:02:27 +00:00
Oli Scherer 83bd12c70f Only inspect user-written predicates for privacy concerns 2024-04-04 14:43:44 +00:00
Oli Scherer cdcca7e8f4 Switch can_eq and can_sub to DefineOpaqueTypes::Yes
They are mostly used in diagnostics anyway
2024-04-04 14:25:45 +00:00
bors 96eaf553e5 Auto merge of #123455 - matthiaskrgr:rollup-b6nu296, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #121546 (Error out of layout calculation if a non-last struct field is unsized)
 - #122448 (Port hir-tree run-make test to ui test)
 - #123212 (CFI: Change type transformation to use TypeFolder)
 - #123218 (Add test for getting parent HIR for synthetic HIR node)
 - #123324 (match lowering: make false edges more precise)
 - #123389 (Avoid panicking unnecessarily on startup)
 - #123397 (Fix diagnostic for qualifier in extern block)
 - #123431 (Stabilize `proc_macro_byte_character` and `proc_macro_c_str_literals`)
 - #123439 (coverage: Remove useless constants)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-04-04 13:10:22 +00:00
Matthias Krüger 4ba3f46be3
Rollup merge of #123439 - Zalathar:constants, r=oli-obk
coverage: Remove useless constants

After #122972 and #123419, these constants don't serve any useful purpose, so get rid of them.

`@rustbot` label +A-code-coverage
2024-04-04 14:51:18 +02:00
Matthias Krüger f254ab08f1
Rollup merge of #123397 - krtab:foreign_fn_qualif_diag, r=petrochenkov
Fix diagnostic for qualifier in extern block

Closes: https://github.com/rust-lang/rust/issues/123306
2024-04-04 14:51:17 +02:00
Matthias Krüger 504a78e2f2
Rollup merge of #123324 - Nadrieril:false-edges2, r=matthewjasper
match lowering: make false edges more precise

When lowering match expressions, we add false edges to hide details of the lowering from borrowck. Morally we pretend we're testing the patterns (and guards) one after the other in order. See the tests for examples. Problem is, the way we implement this today is too coarse for deref patterns.

In deref patterns, a pattern like `deref [1, x]` matches on a `Vec` by creating a temporary to store the output of the call to `deref()` and then uses that to continue matching. Here the pattern has a binding, which we set up after the pre-binding block. Problem is, currently the false edges tell borrowck that the pre-binding block can be reached from a previous arm as well, so the `deref()` temporary may not be initialized. This triggers an error when we try to use the binding `x`.

We could call `deref()` a second time, but this opens the door to soundness issues if the deref impl is weird. Instead in this PR I rework false edges a little bit.

What we need from false edges is a (fake) path from each candidate to the next, specifically from candidate C's pre-binding block to next candidate D's pre-binding block. Today, we link the pre-binding blocks directly. In this PR, I link them indirectly by choosing an earlier node on D's success path. Specifically, I choose the earliest block on D's success path that doesn't make a loop (if I chose e.g. the start block of the whole match (which is on the success path of all candidates), that would make a loop). This turns out to be rather straightforward to implement.

r? `@matthewjasper` if you have the bandwidth, otherwise let me know
2024-04-04 14:51:16 +02:00
Matthias Krüger f03535b297
Rollup merge of #123212 - rcvalle:rust-cfi-use-type-folder, r=compiler-errors
CFI: Change type transformation to use TypeFolder

Change type transformation to use TypeFolder.

cc `@compiler-errors` `@maurer`
2024-04-04 14:51:15 +02:00
Matthias Krüger d5a657c95c
Rollup merge of #121546 - gurry:121473-ice-sizeof-mir-op, r=oli-obk
Error out of layout calculation if a non-last struct field is unsized

Fixes #121473
Fixes #123152
2024-04-04 14:51:14 +02:00
bors ca7d34efa9 Auto merge of #121026 - Zalathar:version, r=oli-obk
coverage: Correctly report and check LLVM's coverage mapping version

I was puzzled by the fact that the LLVM 18 update (#120055) didn't need to modify this version check, despite the fact that LLVM 18 uses a newer version of the coverage mapping format.

This turned out to be because we were inappropriately hard-coding a specific version (`Version6`) in the C++ wrapper, instead of using `CovMapVersion::CurrentVersion` to reflect the version actually used by LLVM on our behalf.

This PR fixes that, and also changes the Rust-side version check to accept the new coverage mapping version used by LLVM 18, since the necessary compatibility work has already been done.

---

### Quick history of `LLVMRustCoverageMappingVersion`:

- Originally it returned LLVM's `coverage::CovMapVersion::CurrentVersion`, as intended. The Rust-side code would verify it, and also embed it as the actual coverage version number in the output binary.
- At some point it was changed to a hard-coded value, to work around a (now-irrelevant) compatibility issue. This was incorrect (but mostly benign), because the override should have been performed on the Rust side instead, after verifying LLVM's value.
- Later contributors dutifully updated the hard-coded value, because they didn't have enough context to identify the problem.
- With this PR, it once again returns LLVM's current coverage version number, and the Rust-side code checks it against an expected range. We don't override the result, but we do indicate where that override should occur if it ever becomes necessary.
2024-04-04 10:45:21 +00:00
Gurinder Singh 313714331a Error out of layout calculation if a non-last struct field is unsized
Fixes an ICE that occurs when a struct with an unsized field
at a non-last position is const evaluated.
2024-04-04 15:50:36 +05:30
Oli Scherer 10e8bca7fe FRU remaining fields does not actually define opaque types 2024-04-04 10:16:52 +00:00
Oli Scherer 95948b75b2 Use DefineOpaqueTypes::Yes since we are guaranteed to error already 2024-04-04 10:16:52 +00:00
Oli Scherer 2247aaf276 Use DefineOpaqueTypes::Yes where the new solver is unconditionally used already 2024-04-04 10:16:52 +00:00
Oli Scherer 82ceed2add Specialization can switch to DefineOpaqueTypes::Yes without having an effect.
The reason is that in specialization graph computation we use `DefiningAnchor::Error`, so there's no difference anyway. And in the other use cases, we

* already errored in the specialization_graph computation, or
* already errored in coherence, or
* are comparing opaque types with inference variables already, or
* there are no opaque types involved
2024-04-04 10:01:45 +00:00
Oli Scherer b54d72264a Use DefineOpaqueTypes::Yes in diagnostics code 2024-04-04 10:01:44 +00:00
Arthur Carcano 109daa2d4b Fix diagnostic for qualifier in extern block
Closes: https://github.com/rust-lang/rust/issues/123306
2024-04-04 11:58:38 +02:00
Oli Scherer 0dca136841 Try explicitly outlining the panic machinery 2024-04-04 09:46:53 +00:00
bors 4c6c629866 Auto merge of #115538 - lcnr:fn-def-wf, r=compiler-errors
check `FnDef` return type for WF

better version of #106807, fixes #84533 (mostly). It's not perfect given that we still ignore WF requirements involving bound regions but I wasn't able to quickly write an example, so even if theoretically exploitable, it should be far harder to trigger.

This is strictly more restrictive than checking the return type for WF as part of the builtin `FnDef: FnOnce` impl (#106807) and moving to this approach in the future will not break any code.

~~It also agrees with my theoretical view of how this should behave~~

r? types
2024-04-04 08:43:53 +00:00
bors 29fe618f75 Auto merge of #123052 - maurer:addr-taken, r=compiler-errors
CFI: Support function pointers for trait methods

Adds support for both CFI and KCFI for function pointers to trait methods by attaching both concrete and abstract types to functions.

KCFI does this through generation of a `ReifyShim` on any function pointer for a method that could go into a vtable, and keeping this separate from `ReifyShim`s that are *intended* for vtable us by setting a `ReifyReason` on them.

CFI does this by setting both the concrete and abstract type on every instance.

This should land after #123024 or a similar PR, as it diverges the implementation of CFI vs KCFI.

r? `@compiler-errors`
2024-04-04 06:40:30 +00:00
bors 43f4f2a3b1 Auto merge of #119820 - lcnr:leak-check-2, r=jackh726
instantiate higher ranked goals outside of candidate selection

This PR modifies `evaluate` to more eagerly instantiate higher-ranked goals, preventing the `leak_check` during candidate selection from detecting placeholder errors involving that binder.

For a general background regarding higher-ranked region solving and the leak check, see https://hackmd.io/qd9Wp03cQVy06yOLnro2Kg.

> The first is something called the **leak check**. You can think of it as a "quick and dirty" approximation for the region check, which will come later. The leak check detects some kinds of errors early, essentially deciding between "this set of outlives constraints are guaranteed to result in an error eventually" or "this set of outlives constraints may be solvable".

## The ideal future

We would like to end up with the following idealized design to handle universal binders:
```rust
fn enter_forall<'tcx, T, R>(
    forall: Binder<'tcx, T>,
    f: impl FnOnce(T) -> R,
) -> R {
    let new_universe = infcx.increment_universe_index();
    let value = instantiate_binder_with_placeholders_in(new_universe, forall);

    let result = f(value);

    eagerly_handle_higher_ranked_region_constraints_in(new_universe);
    infcx.decrement_universe_index();

    assert!(!result.has_placeholders_in_or_above(new_universe));
    result
}
```

That is, when universally instantiating a binder, anything using the placeholders has to happen inside of a limited scope (the closure `f`). After this closure has completed, all constraints involving placeholders are known.

We then handle any *external constraints* which name these placeholders. We destructure `TypeOutlives` constraints involving placeholders and eagerly handle any region constraints involving these placeholders. We do not return anything mentioning the placeholders created inside of this function to the caller.

Being able to eagerly handle *all* region constraints involving placeholders will be difficult due to complex `TypeOutlives` constraints, involving inference variables or alias types, and higher ranked implied bounds. The exact issues and possible solutions are out of scope of this FCP.

#### How does the leak check fit into this

The `leak_check` is an underapproximation of `eagerly_handle_higher_ranked_region_constraints_in`. It detects some kinds of errors involving placeholders from `new_universe`, but not all of them.

It only looks at region outlives constraints, ignoring `TypeOutlives`, and checks whether one of the following two conditions are met for **placeholders in or above `new_universe`**, in which case it results in an error:
- `'!p1: '!p2` a placeholder `'!p2` outlives a different placeholder `'!p1`
- `'!p1: '?2` an inference variable `'?2` outlives a placeholder `'!p1` *which it cannot name*

It does not handle all higher ranked region constraints, so we still return constraints involving placeholders from `new_universe` which are then (re)checked by `lexical_region_resolve` or MIR borrowck.

As we check higher ranked constraints in the full regionck anyways, the `leak_check` is not soundness critical. It's current only purpose is to move some higher ranked region errors earlier, enabling it to guide type inference and trait solving. Adding additional uses of the `leak_check` in the future would only strengthen inference and is therefore not breaking.

## Where do we use currently use the leak check

The `leak_check` is currently used in two places:

Coherence does not use a proper regionck, only relying on the `leak_check` called [at the end of the implicit negative overlap check](8b94152af6/compiler/rustc_trait_selection/src/traits/coherence.rs (L235-L238)). During coherence all parameters are instantiated with inference variables, so the only possible region errors are higher-ranked. We currently also sometimes make guesses when destructuring `TypeOutlives` constraints which can theoretically result in incorrect errors. This could result in overlapping impls.

We also use the `leak_check` [at the end of `fn evaluation_probe`](8b94152af6/compiler/rustc_trait_selection/src/traits/select/mod.rs (L607-L610)). This function is used during candidate assembly for `Trait` goals. Most notably we use [inside of `evaluate_candidate` during winnowing](0e4243538b/compiler/rustc_trait_selection/src/traits/select/mod.rs (L491-L502)). Conceptionally, it is as if we compute each candidate in a separate `enter_forall`.

## The current use in `fn evaluation_probe` is undesirable

Because we only instantiate a higher-ranked goal once inside of `fn evaluation_probe`, errors involving placeholders from that binder can impact selection. This results in inconsistent behavior ([playground](
*[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dac60ebdd517201788899ffa77364831)*)):

```rust
trait Leak<'a> {}
impl Leak<'_>      for Box<u32> {}
impl Leak<'static> for Box<u16> {}

fn impls_leak<T: for<'a> Leak<'a>>() {}

trait IndirectLeak<'a> {}
impl<'a, T: Leak<'a>> IndirectLeak<'a> for T {}
fn impls_indirect_leak<T: for<'a> IndirectLeak<'a>>() {}

fn main() {
    // ok
    //
    // The `Box<u16>` impls fails the leak check,
    // meaning that we apply the `Box<u32>` impl.
    impls_leak::<Box<_>>();

    // error: type annotations needed
    //
    // While the `Box<u16>` impl would fail the leak check
    // we have already instantiated the binder while applying
    // the generic `IndirectLeak` impl, so during candidate
    // selection of `Leak` we do not detect the placeholder error.
    // Evaluation of `Box<_>: Leak<'!a>` is therefore ambiguous,
    // resulting in `for<'a> Box<_>: Leak<'a>` also being ambiguous.
    impls_indirect_leak::<Box<_>>();
}
```

We generally prefer `where`-bounds over implementations during candidate selection, both for [trait goals](11f32b73e0/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1863-L1887)) and during [normalization](11f32b73e0/compiler/rustc_trait_selection/src/traits/project.rs (L184-L198)). However, we currently **do not** use the `leak_check` during candidate assembly in normalizing. This can result in inconsistent behavior:
```rust
trait Trait<'a> {
    type Assoc;
}
impl<'a, T> Trait<'a> for T {
    type Assoc = usize;
}

fn trait_bound<T: for<'a> Trait<'a>>() {}
fn projection_bound<T: for<'a> Trait<'a, Assoc = usize>>() {}

// A function with a trivial where-bound which is more
// restrictive than the impl.
fn function<T: Trait<'static, Assoc = usize>>() {
    // ok
    //
    // Proving `for<'a> T: Trait<'a>` using the where-bound results
    // in a leak check failure, so we use the more general impl,
    // causing this to succeed.
    trait_bound::<T>();

    // error
    //
    // Proving the `Projection` goal `for<'a> T: Trait<'a, Assoc = usize>`
    // does not use the leak check when trying the where-bound, causing us
    // to prefer it over the impl, resulting in a placeholder error.
    projection_bound::<T>();

    // error
    //
    // Trying to normalize the type `for<'a> fn(<T as Trait<'a>>::Assoc)`
    // only gets to `<T as Trait<'a>>::Assoc` once `'a` has been already
    // instantiated, causing us to prefer the where-bound over the impl
    // resulting in a placeholder error. Even if were were to also use the
    // leak check during candidate selection for normalization, this
    // case would still not compile.
    let _higher_ranked_norm: for<'a> fn(<T as Trait<'a>>::Assoc) = |_| ();
}
```

This is also likely to be more performant. It enables more caching in the new trait solver by simply [recursively calling the canonical query][new solver] after instantiating the higher-ranked goal.

It is also unclear how to add the leak check to normalization in the new solver. To handle https://github.com/rust-lang/trait-system-refactor-initiative/issues/1 `Projection` goals are implemented via `AliasRelate`. This again means that we instantiate the binder before ever normalizing any alias. Even if we were to avoid this, we lose the ability to [cache normalization by itself, ignoring the expected `term`](5bd5d214ef/compiler/rustc_trait_selection/src/solve/normalizes_to/mod.rs (L34-L49)). We cannot replace the `term` with an inference variable before instantiating the binder, as otherwise `for<'a> T: Trait<Assoc<'a> = &'a ()>` breaks. If we only replace the term after instantiating the binder, we cannot easily evaluate the goal in a separate context, as [we'd then lose the information necessary for the leak check](11f32b73e0/compiler/rustc_next_trait_solver/src/canonicalizer.rs (L230-L232)). Adding this information to the canonical input also seems non-trivial.

## Proposed solution

I propose to instantiate the binder outside of candidate assembly, causing placeholders from higher-ranked goals to get ignored while selecting their candidate. This mostly[^1] matches the [current behavior of the new solver][new solver]. The impact of this change is therefore as follows:

```rust
trait Leak<'a> {}
impl Leak<'_>      for Box<u32> {}
impl Leak<'static> for Box<u16> {}

fn impls_leak<T: for<'a> Leak<'a>>() {}

trait IndirectLeak<'a> {}
impl<'a, T: Leak<'a>> IndirectLeak<'a> for T {}
fn impls_indirect_leak<T: for<'a> IndirectLeak<'a>>() {}

fn guide_selection() {
    // ok -> ambiguous
    impls_leak::<Box<_>>();

    // ambiguous
    impls_indirect_leak::<Box<_>>();
}

trait Trait<'a> {
    type Assoc;
}
impl<'a, T> Trait<'a> for T {
    type Assoc = usize;
}

fn trait_bound<T: for<'a> Trait<'a>>() {}
fn projection_bound<T: for<'a> Trait<'a, Assoc = usize>>() {}

// A function which a trivial where-bound which is more
// restrictive than the impl.
fn function<T: Trait<'static, Assoc = usize>>() {
    // ok -> error
    trait_bound::<T>();

    // error
    projection_bound::<T>();

    // error
    let _higher_ranked_norm: for<'a> fn(<T as Trait<'a>>::Assoc) = |_| ();
}
```

This does not change the behavior if candidates have higher ranked nested goals, as in this case the `leak_check` causes the nested goal to result in an error ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a74c25300b23db9022226de99d8a2fa6)):
```rust
trait LeakCheckFailure<'a> {}
impl LeakCheckFailure<'static> for () {}

trait Trait<T> {}
impl Trait<u32> for () where for<'a> (): LeakCheckFailure<'a> {}
impl Trait<u16> for () {}
fn impls_trait<T: Trait<U>, U>() {}
fn main() {
    // ok
    //
    // It does not matter whether candidate assembly
    // considers the placeholders from higher-ranked goal.
    //
    // Either `for<'a> (): LeakCheckFailure<'a>` has no
    // applicable candidate or it has a single applicable candidate
    // when then later results in an error. This allows us to
    // infer `U` to `u16`.
    impls_trait::<(), _>()
}
```

## Impact on existing crates

This is a **breaking change**. [A crater run](https://github.com/rust-lang/rust/pull/119820#issuecomment-1926862174) found 17 regressed crates with 7 root causes.

For a full analysis of all affected crates, see https://gist.github.com/lcnr/7c1c652f30567048ea240554a36ed95c.

---

I believe this breakage to be acceptable and would merge this change. I am confident that the new position of the leak check matches our idealized future and cannot envision any other consistent alternative. Where possible, I intend to open PRs fixing/avoiding the regressions before landing this PR.

I originally intended to remove the `coherence_leak_check` lint in the same PR. However, while I am confident in the *position* of the leak check, deciding on its exact behavior is left as future work, cc #112999. This PR therefore only moves the leak check while keeping the lint when relying on it in coherence.

[new solver]: https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/solve/eval_ctxt/mod.rs#L479-L484

[^1]: the new solver has a separate cause of inconsistent behavior rn https://github.com/rust-lang/trait-system-refactor-initiative/issues/53#issuecomment-1914310171

r? `@nikomatsakis`
2024-04-04 04:36:12 +00:00
bors 0accf4ec4c Auto merge of #123440 - jhpratt:rollup-yat6crk, r=jhpratt
Rollup of 4 pull requests

Successful merges:

 - #122356 (std::rand: fix dragonflybsd after #121942.)
 - #123093 (Add a nice header to our README.md)
 - #123307 (Fix f16 and f128 feature gating on different editions)
 - #123401 (Check `x86_64` size assertions on `aarch64`, too)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-04-04 02:11:23 +00:00
Boxy 82789763c7 rebase 2024-04-04 02:14:57 +01:00
lcnr 2b67f0104a check FnDef return type for WF 2024-04-04 01:55:29 +01:00
Jacob Pratt 4332498a6d
Rollup merge of #123401 - Zalathar:assert-size-aarch64, r=fmease
Check `x86_64` size assertions on `aarch64`, too

(Context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Checking.20size.20assertions.20on.20aarch64.3F)

Currently the compiler has around 30 sets of `static_assert_size!` for various size-critical data structures (e.g. various IR nodes), guarded by `#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]`.

(Presumably this cfg avoids having to maintain separate size values for 32-bit targets and unusual 64-bit targets. Apparently it may have been necessary before the i128/u128 alignment changes, too.)

This is slightly incovenient for people on aarch64 workstations (e.g. Macs), because the assertions normally aren't checked until we push to a PR. So this PR adds `aarch64` to the `#[cfg(..)]` guarding all of those assertions in the compiler.

---

Implemented with a simple find/replace. Verified by manually inspecting each `static_assert_size!` in `compiler/`, and checking that either the replacement succeeded, or adding aarch64 wouldn't have been appropriate.
2024-04-03 20:17:06 -04:00
Jacob Pratt 819568a7b4
Rollup merge of #123307 - tgross35:f16-f128-feature-gate-fix, r=petrochenkov
Fix f16 and f128 feature gating on different editions

Apply the fix from https://github.com/rust-lang/rust/issues/123282#issuecomment-2035063388 to correctly gates `f16` and `f128` in editions other than 2015
2024-04-03 20:17:05 -04:00
bors b4acbe4233 Auto merge of #123240 - compiler-errors:assert-args-compat, r=fmease
Assert that args are actually compatible with their generics, rather than just their count

Right now we just check that the number of args is right, rather than actually checking the kinds. Uplift a helper fn that I wrote from trait selection to do just that. Found a couple bugs along the way.

r? `@lcnr` or `@fmease` (or anyone really lol)
2024-04-04 00:09:02 +00:00
Zalathar e08fdb0f2f coverage: Remove useless constants 2024-04-04 11:07:59 +11:00
lcnr 4fa5fb684e move leak check out of candidate evaluation
this prevents higher ranked goals from guiding selection
2024-04-03 22:32:46 +01:00
bors 4fd4797c26 Auto merge of #123429 - matthiaskrgr:rollup-4emw4e9, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #121595 (Better reporting on generic argument mismatchs)
 - #122619 (Fix some unsoundness with PassMode::Cast ABI)
 - #122964 (Rename `expose_addr` to `expose_provenance`)
 - #123291 (Move some tests)
 - #123301 (pattern analysis: fix union handling)
 - #123395 (More postfix match fixes)
 - #123419 (rustc_index: Add a `ZERO` constant to index types)
 - #123421 (Fix target name in NetBSD platform-support doc)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-04-03 20:19:51 +00:00
Matthias Krüger 25b0e84170
Rollup merge of #123419 - petrochenkov:zeroindex, r=compiler-errors
rustc_index: Add a `ZERO` constant to index types

It is commonly used.
2024-04-03 22:11:02 +02:00
Matthias Krüger 202509b427
Rollup merge of #123395 - compiler-errors:postfix-matches-fixes-2, r=petrochenkov
More postfix match fixes

These affect diagnostics only, as far as I can tell. I'm too lazy to come up with UI tests, but I could be convinced otherwise.

Specifically, I think changing the precedence computation actually doesn't change anything, but tweaking `contains_exterior_struct_lit` does mean that some diagnostics will begin parenthesizing `S {}.match {}`.
2024-04-03 22:11:01 +02:00
Matthias Krüger 5f74403c8e
Rollup merge of #123301 - Nadrieril:unions, r=compiler-errors
pattern analysis: fix union handling

Little known fact: rust supports union patterns. Exhaustiveness handles them soundly but reports nonsensical missing patterns. This PR fixes the reported patterns and documents what we're doing.

r? `@compiler-errors`
2024-04-03 22:11:01 +02:00
Matthias Krüger 80d592cc24
Rollup merge of #122964 - joboet:pointer_expose, r=Amanieu
Rename `expose_addr` to `expose_provenance`

`expose_addr` is a bad name, an address is just a number and cannot be exposed. The operation is actually about the provenance of the pointer.

This PR thus changes the name of the method to `expose_provenance` without changing its return type. There is sufficient precedence for returning a useful value from an operation that does something else without the name indicating such, e.g. [`Option::insert`](https://doc.rust-lang.org/nightly/std/option/enum.Option.html#method.insert) and [`MaybeUninit::write`](https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.write).

Returning the address is merely convenient, not a fundamental part of the operation. This is implied by the fact that integers do not have provenance since
```rust
let addr = ptr.addr();
ptr.expose_provenance();
let new = ptr::with_exposed_provenance(addr);
```
must behave exactly like
```rust
let addr = ptr.expose_provenance();
let new = ptr::with_exposed_provenance(addr);
```
as the result of `ptr.expose_provenance()` and `ptr.addr()` is the same integer. Therefore, this PR removes the `#[must_use]` annotation on the function and updates the documentation to reflect the important part.

~~An alternative name would be `expose_provenance`. I'm not at all opposed to that, but it makes a stronger implication than we might want that the provenance of the pointer returned by `ptr::with_exposed_provenance`[^1] is the same as that what was exposed, which is not yet specified as such IIUC. IMHO `expose` does not make that connection.~~

A previous version of this PR suggested `expose` as name, libs-api [decided on](https://github.com/rust-lang/rust/pull/122964#issuecomment-2033194319) `expose_provenance` to keep the symmetry with `with_exposed_provenance`.

CC `@RalfJung`
r? libs-api

[^1]: I'm using the new name for `from_exposed_addr` suggested by #122935 here.
2024-04-03 22:11:00 +02:00
Matthias Krüger bc8415b9e6
Rollup merge of #122619 - erikdesjardins:cast, r=compiler-errors
Fix some unsoundness with PassMode::Cast ABI

Fixes #122617

Reviewable commit-by-commit. More info in each commit message.
2024-04-03 22:11:00 +02:00
Matthias Krüger 32c8c5cb7e
Rollup merge of #121595 - strottos:issue_116615, r=compiler-errors
Better reporting on generic argument mismatchs

This allows better reporting as per issue #116615 .

If you have a function:
```
fn foo(a: T, b: T) {}
```
and call it like so:
```
foo(1, 2.)
```
it'll give improved error reported similar to the following:
```
error[E0308]: mismatched types
 --> generic-mismatch-reporting-issue-116615.rs:6:12
  |
6 |     foo(1, 2.);
  |     --- -  ^^ expected integer, found floating-point number
  |     |   |
  |     |   expected argument `b` to be an integer because that argument needs to match the type of this parameter
  |     arguments to this function are incorrect
  |
note: function defined here
 --> generic-mismatch-reporting-issue-116615.rs:1:4
  |
1 | fn foo<T>(a: T, b: T) {}
  |    ^^^ -  ----  ----
  |        |  |     |
  |        |  |     this parameter needs to match the integer type of `a`
  |        |  `b` needs to match the type of this parameter
  |        `a` and `b` all reference this parameter T
```

Open question, do we need to worry about error message translation into other languages? Not sure what the status of that is in Rust.

NB: Needs some checking over and some tests have altered that need sanity checking, but overall this is starting to get somewhere now. Will take out of draft PR status when this has been done, raising now to allow feedback at this stage, probably 90% ready.
2024-04-03 22:10:59 +02:00
Trevor Gross 5afe072ead Fix f16 and f128 feature gates in editions other than 2015
Fixes https://github.com/rust-lang/rust/issues/123282

Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2024-04-03 16:03:22 -04:00
Nadrieril 8021192d34 More precise false edges 2024-04-03 21:02:47 +02:00
Nadrieril 8f80259f10 Explain false edges in more detail 2024-04-03 21:02:47 +02:00
bors 98efd808e1 Auto merge of #123415 - petrochenkov:parenting, r=compiler-errors
hir: Drop owner's own item-local id (zero) from parenting tables

I expect this to be a common case.
2024-04-03 18:18:44 +00:00
Vadim Petrochenkov b40ea03f8a rustc_index: Add a ZERO constant to index types
It is commonly used.
2024-04-03 19:06:22 +03:00
Michael Goulet bd8ca780a5 Fix up error message for debug_assert_args_compat for IATs 2024-04-03 11:18:56 -04:00
Michael Goulet 03163ef9d9 Don't fill non-ty args with ty::Error 2024-04-03 11:18:56 -04:00
Michael Goulet 657dadf2cc Simplify some cfging 2024-04-03 11:18:56 -04:00
Michael Goulet c9f8529793 Uplift and start using check_args_compatible more liberally 2024-04-03 11:18:55 -04:00