Commit Graph

2275 Commits

Author SHA1 Message Date
Esteban Küber
4e6a401b22 review comments: reword messages and simplify logic 2024-12-04 20:49:05 +00:00
Esteban Küber
d136b3108d Add more context to fall-through "const pattern of non-structural type" error
Point at types that need to be marked with `#[derive(PartialEq)]`.

We use a visitor to look at a type that isn't structural, looking for all ADTs that don't derive `PartialEq`. These can either be manual `impl PartialEq`s or no `impl` at all, so we differentiate between those two cases to provide more context to the user. We also only point at types and impls from the local crate, otherwise show only a note.

```
error: constant of non-structural type `&[B]` in a pattern
  --> $DIR/issue-61188-match-slice-forbidden-without-eq.rs:15:9
   |
LL | struct B(i32);
   | -------- must be annotated with `#[derive(PartialEq)]` to be usable in patterns
LL |
LL | const A: &[B] = &[];
   | ------------- constant defined here
...
LL |         A => (),
   |         ^ constant of non-structural type
   |
   = note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details
```
2024-12-04 20:29:36 +00:00
Esteban Küber
27a1880593 Add context to fall-through "const pattern of non-structural type" error
Unify wording with the regular non-structural type error.
2024-12-04 20:29:36 +00:00
Esteban Küber
335d05aee5 Add additional context for non-sructural type constant used in pattern
- Point at type that should derive `PartialEq` to be structural.
- Point at manual `impl PartialEq`, explaining that it is not sufficient to be structural.

```
error: constant of non-structural type `MyType` in a pattern
  --> $DIR/const-partial_eq-fallback-ice.rs:14:12
   |
LL | struct MyType;
   | ------------- `MyType` must be annotated with `#[derive(PartialEq)]` to be usable in patterns
...
LL | const CONSTANT: &&MyType = &&MyType;
   | ------------------------ constant defined here
...
LL |     if let CONSTANT = &&MyType {
   |            ^^^^^^^^ constant of non-structural type
   |
note: the `PartialEq` trait must be derived, manual `impl`s are not sufficient; see https://doc.rust-lang.org/stable/std/marker/trait.StructuralPartialEq.html for details
  --> $DIR/const-partial_eq-fallback-ice.rs:5:1
   |
LL | impl PartialEq<usize> for MyType {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
2024-12-04 20:29:36 +00:00
Esteban Küber
fb2f6a44c0 Reword message for non-structural type constant in pattern 2024-12-04 20:29:36 +00:00
Esteban Küber
a6040bc230 Specify type kind of constant that can't be used in patterns
```
error: trait object `dyn Send` cannot be used in patterns
  --> $DIR/issue-70972-dyn-trait.rs:6:9
   |
LL | const F: &'static dyn Send = &7u32;
   | -------------------------- constant defined here
...
LL |         F => panic!(),
   |         ^ trait object can't be used in patterns
```
2024-12-04 20:29:36 +00:00
Esteban Küber
253eb95d45 Tweak output of some const pattern errors
- Add primary span labels.
- Point at const generic parameter used as pattern.
- Point at statics used as pattern.
- Point at let bindings used in const pattern.
2024-12-04 20:29:36 +00:00
Esteban Küber
87ddc1ea33 Point at generic param through which a const is used in a pattern
```
error[E0158]: constant pattern depends on a generic parameter, which is not allowed
  --> $DIR/associated-const-type-parameter-pattern.rs:20:9
   |
LL | pub trait Foo {
   | -------------
LL |     const X: EFoo;
   |     ------------- constant defined here
...
LL | pub fn test<A: Foo, B: Foo>(arg: EFoo) {
   |             - constant depends on this generic param
LL |     match arg {
LL |         A::X => println!("A::X"),
   |         ^^^^ `const` depends on a generic parameter
```
2024-12-04 20:29:36 +00:00
Esteban Küber
c0f00086f8 Tweak ptr in pattern error
Conform to error style guide.
2024-12-04 20:29:36 +00:00
Esteban Küber
cc492edc9d Tweak unevaluated constant in pattern error
Silence errors that are implied by the errors in the `const` item definition.

Add a primary span label.
2024-12-04 20:29:35 +00:00
Esteban Küber
c6205055e0 On const pattern errors, point at the const item definition
Centralize emitting an error in `const_to_pat` so that all errors from that evaluating a `const` in a pattern can add addditional information. With this, now point at the `const` item's definition:

```
error[E0158]: constant pattern depends on a generic parameter
  --> $DIR/associated-const-type-parameter-pattern.rs:20:9
   |
LL | pub trait Foo {
   | -------------
LL |     const X: EFoo;
   |     ------------- constant defined here
...
LL |         A::X => println!("A::X"),
   |         ^^^^
```
2024-12-04 20:29:35 +00:00
Scott McMurray
612adbb6bf Bounds-check with PtrMetadata instead of Len in MIR 2024-12-03 11:05:45 -08:00
lcnr
e089bead32 remove Ty::is_copy_modulo_regions 2024-12-02 13:57:56 +01:00
Maybe Lapkin
144d6cc65b
simplify things using tcx.as_lang_item 2024-11-29 20:28:02 +01:00
Maybe Lapkin
c6454dd582
don't polymorphize without a reason to 2024-11-29 20:27:24 +01:00
Maybe Lapkin
ef5808a035
add a fixme for tailcalls with opaque types 2024-11-29 20:26:30 +01:00
Maybe Lapkin
d93ea6bc79
simplify things by using tcx.fn_trait_kind_from_def_id 2024-11-29 20:25:57 +01:00
Maybe Waffle
cfb78419cd
implement checks for tail calls
this implements checks necessary to guarantee that we can actually
perform a tail call. while extremely restrictive, this is what is
documented in the RFC, and all these checks are needed for one reason or
another.
2024-11-29 04:44:41 +01:00
Maybe Lapkin
8e77349782
fix a comment with uneven number of backticks in rustc_mir_build
this is funny though! apparently tidy parsed `.gitignore`, but did not
recognize unignore lines (`!...`), so tidy was ignoring `rustc_mir_build`
this whole time (at least for some lints?).
2024-11-28 21:54:27 +01:00
bors
e48241b5d1 Auto merge of #131859 - chriskrycho:update-trpl, r=onur-ozkan
Update TRPL to add new Chapter 17: Async and Await

- Add support to `rustbook` to pass through the `-L`/`--library-path` flag to `mdbook` so that references to the `trpl` crate
- Build the `trpl` crate as part of the book tests. Make it straightforward to add other such book dependencies in the future if needed by implementing that in a fairly general way.
- Update the submodule for the book to pull in the new chapter on async and await, as well as a number of other fixes. This will happen organically/automatically in a week, too, but this lets me group this change with the next one:
- Update the compiler messages which reference the existing chapters 17–20, which are now chapters 18-21. There are only two, both previously referencing chapter 18.
- Update the UI tests which reference the compiler message outputs.
2024-11-23 23:26:19 +00:00
Chris Krycho
5e3607626d
Update messages which reference book chs. 17-20
With the insertion of a new chapter 17 on async and await to _The Rust
Programming Language_, references in compiler output to later chapters
need to be updated to avoid confusing users. Redirects exist so that
users who click old links will end up in the right place anyway, but
this way users will be directed to the right URL in the first place.
2024-11-23 08:57:24 -07:00
lcnr
a8c8ab1acd remove remaining references to Reveal 2024-11-23 13:52:56 +01:00
lcnr
319843d8cd no more Reveal :( 2024-11-23 13:52:54 +01:00
lcnr
f4b516b10c thir building: use typing_env directly 2024-11-23 13:51:57 +01:00
bors
6e1c11591f Auto merge of #132915 - veluca93:unsafe-fields, r=jswrenn
Implement the unsafe-fields RFC.

RFC: rust-lang/rfcs#3458

Tracking:

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

r? jswrenn
2024-11-23 07:47:52 +00:00
Michael Goulet
d2fb8b5feb
Rollup merge of #132658 - estebank:const-in-pattern-typo, r=Nadrieril
Detect const in pattern with typo

When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.

```
error: unreachable pattern
  --> $DIR/const-with-typo-in-pattern-binding.rs:30:9
   |
LL |         GOOOD => {}
   |         ----- matches any value
LL |
LL |         _ => {}
   |         ^ no value can reach this
   |
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
   |
LL |         GOOD => {}
   |         ~~~~
```

Fix #132582.
2024-11-22 21:07:38 -05:00
Luca Versari
9022bb2d6f Implement the unsafe-fields RFC.
Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
2024-11-21 19:32:07 +01:00
Matthias Krüger
395649558a
Rollup merge of #131544 - nbdd0121:asm_goto_safe_block, r=petrochenkov
Make asm label blocks safe context

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

`asm!()` is forced to be wrapped inside unsafe. If there's no special treatment, the label blocks would also always be unsafe with no way of opting out. It was suggested that a simple fix is to make asm label blocks safe: https://github.com/rust-lang/rust/issues/119364#issuecomment-2316037703.

`@rustbot` labels: +A-inline-assembly +F-asm
2024-11-21 11:58:37 +01:00
bors
2d0ea7956c Auto merge of #133261 - matthiaskrgr:rollup-ekui4we, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #129838 (uefi: process: Add args support)
 - #130800 (Mark `get_mut` and `set_position` in `std::io::Cursor` as const.)
 - #132708 (Point at `const` definition when used instead of a binding in a `let` statement)
 - #133226 (Make `PointerLike` opt-in instead of built-in)
 - #133244 (Account for `wasm32v1-none` when exporting TLS symbols)
 - #133257 (Add `UnordMap::clear` method)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-11-20 21:58:38 +00:00
Matthias Krüger
7fc2b33722
Rollup merge of #132708 - estebank:const-as-binding, r=Nadrieril
Point at `const` definition when used instead of a binding in a `let` statement

Modify `PatKind::InlineConstant` to be `ExpandedConstant` standing in not only for inline `const` blocks but also for `const` items. This allows us to track named `const`s used in patterns when the pattern is a single binding. When we detect that there is a refutable pattern involving a `const` that could have been a binding instead, we point at the `const` item, and suggest renaming. We do this for both `let` bindings and `match` expressions missing a catch-all arm if there's at least one single binding pattern referenced.

After:

```
error[E0005]: refutable pattern in local binding
  --> $DIR/bad-pattern.rs:19:13
   |
LL |     const PAT: u32 = 0;
   |     -------------- missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable
...
LL |         let PAT = v1;
   |             ^^^ pattern `1_u32..=u32::MAX` not covered
   |
   = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
   = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
   = note: the matched value is of type `u32`
help: introduce a variable instead
   |
LL |         let PAT_var = v1;
   |             ~~~~~~~
```

Before:

```
error[E0005]: refutable pattern in local binding
  --> $DIR/bad-pattern.rs:19:13
   |
LL |         let PAT = v1;
   |             ^^^
   |             |
   |             pattern `1_u32..=u32::MAX` not covered
   |             missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable
   |             help: introduce a variable instead: `PAT_var`
   |
   = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
   = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
   = note: the matched value is of type `u32`
```

CC #132582.
2024-11-20 20:10:12 +01:00
Esteban Küber
2487765b88 Detect const in pattern with typo
When writing a constant name incorrectly in a pattern, the pattern will be identified as a new binding. We look for consts in the current crate, consts that where imported in the current crate and for local `let` bindings in case someone got them confused with `const`s.

```
error: unreachable pattern
  --> $DIR/const-with-typo-in-pattern-binding.rs:30:9
   |
LL |         GOOOD => {}
   |         ----- matches any value
LL |
LL |         _ => {}
   |         ^ no value can reach this
   |
help: you might have meant to pattern match against the value of similarly named constant `GOOD` instead of introducing a new catch-all binding
   |
LL |         GOOD => {}
   |         ~~~~
```

Fix #132582.
2024-11-20 17:55:18 +00:00
Ding Xiang Fei
297b618944
reduce false positives of tail-expr-drop-order from consumed values
take 2

open up coroutines

tweak the wordings

the lint works up until 2021

We were missing one case, for ADTs, which was
causing `Result` to yield incorrect results.

only include field spans with significant types

deduplicate and eliminate field spans

switch to emit spans to impl Drops

Co-authored-by: Niko Matsakis <nikomat@amazon.com>

collect drops instead of taking liveness diff

apply some suggestions and add explantory notes

small fix on the cache

let the query recurse through coroutine

new suggestion format with extracted variable name

fine-tune the drop span and messages

bugfix on runtime borrows

tweak message wording

filter out ecosystem types earlier

apply suggestions

clippy

check lint level at session level

further restrict applicability of the lint

translate bid into nop for stable mir

detect cycle in type structure
2024-11-20 20:53:11 +08:00
lcnr
07a5272476 pattern lowering, yeet TypingEnv::from_param_env 2024-11-19 18:06:20 +01:00
lcnr
1ec964873e unconditional recursion, yeet TypingEnv::from_param_env 2024-11-19 18:06:20 +01:00
lcnr
948cec0fad move fn is_item_raw to TypingEnv 2024-11-19 18:06:20 +01:00
lcnr
2e087d2eaa review 2024-11-18 10:50:14 +01:00
lcnr
9cba14b95b use TypingEnv when no infcx is available
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
2024-11-18 10:38:56 +01:00
Esteban Küber
29acf8b422 Account for ExpandedConstant in parse_match 2024-11-17 23:58:22 +00:00
Esteban Küber
6480b76e45 review comments
- Remove check for "how many path segments is the pattern"
- Check before suggesting if the path has multiple path segments
2024-11-17 23:40:00 +00:00
Esteban Küber
bb37e5d3cd review comments 2024-11-17 23:40:00 +00:00
Esteban Küber
f1772d5739 Make suggestion verbose 2024-11-17 23:40:00 +00:00
Esteban Küber
f563efec15 Unify expanded constants and named constants in PatKind 2024-11-17 23:40:00 +00:00
Esteban Küber
a5b4d458a1 Point at const when intended binding fall-through pattern is a const
```
error[E0004]: non-exhaustive patterns: `i32::MIN..=3_i32` and `5_i32..=i32::MAX` not covered
  --> $DIR/intended-binding-pattern-is-const.rs:2:11
   |
LL |     match 1 {
   |           ^ patterns `i32::MIN..=3_i32` and `5_i32..=i32::MAX` not covered
LL |         x => {}
   |         - this pattern doesn't introduce a new catch-all binding, but rather pattern matches against the value of constant `x`
   |
   = note: the matched value is of type `i32`
note: constant `x` defined here
  --> $DIR/intended-binding-pattern-is-const.rs:7:5
   |
LL |     const x: i32 = 4;
   |     ^^^^^^^^^^^^
help: if you meant to introduce a binding, use a different name
   |
LL |         x_var => {}
   |          ++++
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern, a match arm with multiple or-patterns as shown, or multiple match arms
   |
LL |         x => {}, i32::MIN..=3_i32 | 5_i32..=i32::MAX => todo!()
   |                ++++++++++++++++++++++++++++++++++++++++++++++++
```
2024-11-17 23:40:00 +00:00
Esteban Küber
6dc79f6133 Use item_name instead of a span snippet when talking about const pattern 2024-11-17 23:40:00 +00:00
Esteban Küber
c25b44bee9 Fold PatKind::NamedConstant into PatKind::Constant 2024-11-17 23:39:59 +00:00
Esteban Küber
ff2f7a7a83 Point at const definition when used instead of a binding in a let statement
After:

```
error[E0005]: refutable pattern in local binding
  --> $DIR/bad-pattern.rs:19:13
   |
LL |     const PAT: u32 = 0;
   |     -------------- missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable
...
LL |         let PAT = v1;
   |             ^^^
   |             |
   |             pattern `1_u32..=u32::MAX` not covered
   |             help: introduce a variable instead: `PAT_var`
   |
   = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
   = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
   = note: the matched value is of type `u32`
```

Before:

```
error[E0005]: refutable pattern in local binding
  --> $DIR/bad-pattern.rs:19:13
   |
LL |         let PAT = v1;
   |             ^^^
   |             |
   |             pattern `1_u32..=u32::MAX` not covered
   |             missing patterns are not covered because `PAT` is interpreted as a constant pattern, not a new variable
   |             help: introduce a variable instead: `PAT_var`
   |
   = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
   = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
   = note: the matched value is of type `u32`
```
2024-11-17 23:39:59 +00:00
bors
5700240aff Auto merge of #132943 - matthiaskrgr:rollup-164l3ej, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #132651 (Remove attributes from generics in built-in derive macros)
 - #132668 (Feature gate yield expressions not in 2024)
 - #132771 (test(configure): cover `parse_args` in `src/bootstrap/configure.py`)
 - #132895 (Generalize `NonNull::from_raw_parts` per ACP362)
 - #132914 (Update grammar in std::cell docs.)
 - #132927 (Consolidate type system const evaluation under `traits::evaluate_const`)
 - #132935 (Make sure to ignore elided lifetimes when pointing at args for fulfillment errors)
 - #132941 (Subtree update of `rust-analyzer`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-11-12 08:15:38 +00:00
Matthias Krüger
2ad4a3568d
Rollup merge of #132627 - adwinwhite:thir_body_cleanup, r=compiler-errors
cleanup: Remove outdated comment of `thir_body`

When typeck fails, `thir_body` returns `ErrorGuaranteed` rather than empty body.

No other code follows this outdated description except `check_unsafety`, which is also cleaned up in this PR.
2024-11-12 06:27:17 +01:00
Boxy
bea0148ac6 Consolidate type system const evaluation under traits::evaluate_const
mew
2024-11-12 02:54:03 +00:00
bors
096277e989 Auto merge of #132580 - compiler-errors:globs, r=Noratrieb
Remove unnecessary pub enum glob-imports from `rustc_middle::ty`

We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly.

`@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`.

This PR is a bit large, but it's just naming.

The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine.

r? `@noratrieb` or reassign
2024-11-05 08:30:56 +00:00
Adwin White
15a71b64b8 cleanup: Remove outdated comment and logic of thir_body 2024-11-05 12:41:52 +08:00
Michael Goulet
e03e9abe3c Register const preds for Deref adjustments in HIR typeck 2024-11-04 04:51:31 +00:00
Michael Goulet
883f8705d4 Remove BorrowKind glob, make names longer 2024-11-04 04:45:52 +00:00
bjorn3
760338526f Show actual MIR when MIR building forgot to terminate block
This makes it significantly easier to debug bugs of this kind.
2024-11-01 11:24:14 +01:00
Jubilee
6da4221d96
Rollup merge of #132385 - workingjubilee:move-abi-to-rustc-abi, r=jieyouxu,compiler-errors
compiler: Move `rustc_target::spec::abi::Abi` to `rustc_abi::ExternAbi`

Lift `enum Abi` from its rather odd place in the middle of rustc_target, and make it available again from rustc_abi. You know, the crate where you would expect the enum that describes all the ABIs to be? The platform-neutral ones, at least. This will help further refactoring of how we handle ABIs in the near future[^0].

Rename `Abi` to `ExternAbi` because quite a lot of the compiler overloads the concept of "ABI" enough that the existing name is imprecise and it is often renamed _anyway_. Often this was to avoid conflicts with the *other* type formerly known as `Abi` (now named BackendRepr[^1]), but sometimes it is just for clarity, and this name seems more self-explanatory. It does get reexported, though, using its old name, to reduce the odds of merge-conflicting over the entire tree.

All of `ExternAbi`'s friends come along for the ride, which costs adding some optional dependencies to the rustc_abi crate. However, all of this also allows simply moving three crates entirely off rustc_target:
- rustc_hir_pretty
- rustc_lint_defs
- rustc_mir_build

This odd selection is mostly to demonstrate a secondary motivation: The majority of the front-end of the compiler should be as target-agnostic as possible, and it is easier to assure this if they simply don't depend on the crate that describes targets. Note that I didn't migrate crates that don't benefit from it in this way yet, and I didn't survey every last crate.

[^0]: This is being undertaken as part of https://github.com/rust-lang/rust/issues/119183
[^1]: https://github.com/rust-lang/rust/pull/132246
2024-10-31 17:50:42 -07:00
bors
9ccfedf186 Auto merge of #132301 - compiler-errors:adjust, r=lcnr
Remove region from adjustments

It's not necessary to store this region, because it's only used in THIR and MemCat/ExprUse, both of which already basically only deal with erased regions anyways.
2024-10-31 10:17:49 +00:00
Jubilee Young
8a0e64078e compiler: Switch to rustc_abi in hir_pretty, lint_defs, and mir_build
Completely abandon usage of rustc_target in these crates, as
they need no special knowledge of rustc's target tuples.
2024-10-30 22:38:49 -07:00
Jubilee
847b6fe6b0
Rollup merge of #132246 - workingjubilee:campaign-on-irform, r=compiler-errors
Rename `rustc_abi::Abi` to `BackendRepr`

Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights.

Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
2024-10-30 14:01:37 -07:00
Matthias Krüger
305508f969
Rollup merge of #131856 - lcnr:typing-mode, r=compiler-errors
TypingMode: merge intercrate, reveal, and defining_opaque_types

This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in #132279 and via `FIXME`s.

Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists.

As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`.

#### `TypingMode::from_param_env`

I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc #124598

r? ``@compiler-errors``
2024-10-30 06:40:34 +01:00
Matthias Krüger
87d348b333
Rollup merge of #129394 - Jarcho:irrefutable_let_patterns, r=Nadrieril
Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains

fixes #128661

Is there any preference where the test goes? There looks to be several places it could fit.
2024-10-30 06:40:34 +01:00
Jubilee Young
7086dd83cc compiler: rustc_abi::Abi => BackendRepr
The initial naming of "Abi" was an awful mistake, conveying wrong ideas
about how psABIs worked and even more about what the enum meant.
It was only meant to represent the way the value would be described to
a codegen backend as it was lowered to that intermediate representation.
It was never meant to mean anything about the actual psABI handling!
The conflation is because LLVM typically will associate a certain form
with a certain ABI, but even that does not hold when the special cases
that actually exist arise, plus the IR annotations that modify the ABI.

Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename
`BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to
the persistent misunderstandings, this too is now incorrect:
- Scattered ABI-relevant code is entangled with BackendRepr
- We do not always pre-compute a correct BackendRepr that reflects how
  we "actually" want this value to be handled, so we leave the backend
  interface to also inject various special-cases here
- In some cases `BackendRepr::Memory` is a "real" aggregate, but in
  others it is in fact using memory, and in some cases it is a scalar!

Our rustc-to-backend lowering code handles this sort of thing right now.
That will eventually be addressed by lifting duplicated lowering code
to either rustc_codegen_ssa or rustc_target as appropriate.
2024-10-29 14:56:00 -07:00
Jason Newcomb
4a2e08af22 Don't lint irrefutable_let_patterns on leading patterns if else if let-chains. 2024-10-29 14:43:50 -04:00
Matthias Krüger
5d6c49938e
Rollup merge of #131984 - dingxiangfei2009:stabilize-if-let-rescope, r=traviscross,lcnr
Stabilize if_let_rescope

Close #131154
Tracked by #124085
2024-10-29 18:38:57 +01:00
lcnr
f51ec110a7 TypingMode 🤔 2024-10-29 17:01:24 +01:00
Michael Goulet
599ffab6cd Remove region from adjustments 2024-10-29 01:34:06 +00:00
Matthias Krüger
93bf791e8b
Rollup merge of #129248 - compiler-errors:raw-ref-deref, r=nnethercote
Taking a raw ref (`&raw (const|mut)`) of a deref of pointer (`*ptr`) is always safe

T-opsem decided in https://github.com/rust-lang/reference/pull/1387 that `*ptr` is only unsafe if the place is accessed. This means that taking a raw ref of a deref expr is always safe, since it doesn't constitute a read.

This also relaxes the `DEREF_NULLPTR` lint to stop warning in the case of raw ref of a deref'd nullptr, and updates its docs to reflect that change in the UB specification.

This does not change the behavior of `addr_of!((*ptr).field)`, since field projections still require the projection is in-bounds.

I'm on the fence whether this requires an FCP, since it's something that is guaranteed by the reference you could ostensibly call this a bugfix since we were counting truly safe operations as unsafe. Perhaps someone on opsem has a strong opinion? cc `@rust-lang/opsem`
2024-10-24 10:35:39 +02:00
Stuart Cook
4b02d642dd
Rollup merge of #131909 - clubby789:enum-overflow-cast, r=compiler-errors
Prevent overflowing enum cast from ICEing

Fixes #131902
2024-10-24 14:19:56 +11:00
Ding Xiang Fei
6d569f769c
stabilize if_let_rescope 2024-10-24 04:33:14 +08:00
León Orell Valerian Liehr
8b1141a5c3
Rollup merge of #132060 - joshtriplett:innermost-outermost, r=jieyouxu
"innermost", "outermost", "leftmost", and "rightmost" don't need hyphens

These are all standard dictionary words and don't require hyphenation.

-----

Encountered an instance of this in error messages and it bugged me, so I
figured I'd fix it across the entire codebase.
2024-10-23 22:11:05 +02:00
Josh Triplett
ecdc2441b6 "innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
2024-10-23 02:45:24 -07:00
Ralf Jung
ad3991d303 nightly feature tracking: get rid of the per-feature bool fields 2024-10-23 09:14:41 +01:00
Michael Goulet
6f6f91ab82 Rip out old effects var handling code from traits 2024-10-20 13:40:22 +00:00
clubby789
ab4222ad97 Prevent overflowing enum cast from ICEing 2024-10-19 09:44:37 +00:00
Matthias Krüger
c1ed1f133e
Rollup merge of #131381 - Nadrieril:min-match-ergonomics, r=pnkfelix
Implement edition 2024 match ergonomics restrictions

This implements the minimalest version of [match ergonomics for edition 2024](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html). This minimal version makes it an error to ever reset the default binding mode. The implemented proposal is described precisely [here](https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q#RFC-3627-nano), where it is called "RFC 3627-nano".

Rules:
- Rule 1C: When the DBM (default binding mode) is not `move` (whether or not behind a reference), writing `mut`, `ref`, or `ref mut` on a binding is an error.
- Rule 2C: Reference patterns can only match against references in the scrutinee when the DBM is `move`.

This minimal version is forward-compatible with the main proposals for match ergonomics 2024: [RFC3627](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html) itself, the alternative [rule 4-early variant](https://rust-lang.github.io/rfcs/3627-match-ergonomics-2024.html), and [others](https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q). The idea is to give us more time to iron out a final proposal.

This includes a migration lint that desugars any offending pattern into one that doesn't make use of match ergonomics. Such patterns have identical meaning across editions.

This PR insta-stabilizes the proposed behavior onto edition 2024.

r? `@ghost`

Tracking:

- https://github.com/rust-lang/rust/issues/123076
2024-10-16 19:18:30 +02: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
Gary Guo
809dc73d90 Make asm label blocks safe context
`asm!()` is forced to be wrapped inside unsafe. If there's no special
treatment, the label blocks would also always be unsafe with no way
of opting out.
2024-10-11 11:54:30 +01:00
zhuyunxing
6e3e19f714 coverage. Adapt to mcdc mapping formats introduced by llvm 19 2024-10-08 11:15:24 +08:00
zhuyunxing
99bd601df5 coverage. MCDC ConditionId start from 0 to keep with llvm 19 2024-10-08 10:50:18 +08: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
4107322766 Error on resetted binding mode in edition 2024 2024-10-08 00:23:28 +02:00
Michael Goulet
367183bc0c Don't emit null pointer lint for raw ref of null deref 2024-10-06 22:36:51 -04:00
Michael Goulet
f2a80a0f89 A raw ref of a deref is always safe 2024-10-06 22:35:40 -04: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
Michael Goulet
e3a0da1863 Remove unnamed field feature 2024-10-01 13:55:46 -04:00
Ralf Jung
c55c4c9f9d tweak Const::identity_unevaluated name and docs 2024-09-28 21:28:08 +02:00
Ralf Jung
921a5ef6d7 try to get rid of mir::Const::normalize 2024-09-28 21:15:18 +02:00
Lukas Markeffsky
bd31e3ed70 be even more precise about "cast" vs "coercion" 2024-09-24 23:12:02 +02:00
Lukas Markeffsky
d1e82d438f use more accurate spans for user type ascriptions 2024-09-24 22:20:42 +02:00
Lukas Markeffsky
46ecb23198 unify dyn* coercions with other pointer coercions 2024-09-24 22:17:55 +02:00
Matthias Krüger
0e08d7002b
Rollup merge of #130715 - compiler-errors:mir-build-const-eval, r=BoxyUwU
Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis

We normalize consts in writeback: #130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`.

Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺
2024-09-23 06:45:36 +02:00
Michael Goulet
c682aa162b Reformat using the new identifier sorting from rustfmt 2024-09-22 19:11:29 -04:00
Michael Goulet
2273aeed9d Replace calls to Const::eval in mir build 2024-09-22 14:12:37 -04:00
Guillaume Gomez
fe5f734e6a
Rollup merge of #130526 - eholk:pin-reborrow, r=compiler-errors
Begin experimental support for pin reborrowing

This commit adds basic support for reborrowing `Pin` types in argument position. At the moment it only supports reborrowing `Pin<&mut T>` as `Pin<&mut T>` by inserting a call to `Pin::as_mut()`, and only in argument position (not as the receiver in a method call).

This PR makes the following example compile:

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

fn foo(_: Pin<&mut Foo>) {
}

fn bar(mut x: Pin<&mut Foo>) {
    foo(x);
    foo(x);
}
```

Previously, you would have had to write `bar` as:

```rust
fn bar(mut x: Pin<&mut Foo>) {
    foo(x.as_mut());
    foo(x);
}
```

Tracking:

- #130494

r? `@compiler-errors`
2024-09-20 19:46:38 +02:00
Eric Holk
a18800f807
pin_ergonomics: allow reborrowing as Pin<&T> 2024-09-19 16:28:19 -07:00
Eric Holk
b2b76fb706
Allow shortening reborrows
Generating a call to `as_mut()` let to more restrictive borrows than
what reborrowing usually gives us. Instead, we change the desugaring to
reborrow the pin internals directly which makes things more expressive.
2024-09-19 15:34:00 -07:00
Jubilee
f9b8ef0687
Rollup merge of #130533 - compiler-errors:never-pat-unsafeck, r=Nadrieril
Never patterns constitute a read for unsafety

This code is otherwise unsound if we don't emit an unsafety error here. Noticed when fixing #130528, but it's totally unrelated.

r? `@Nadrieril`
2024-09-18 23:40:30 -07:00
Michael Goulet
e138e8760d Never patterns constitute a read for unsafety 2024-09-18 19:17:38 -04:00
Michael Goulet
12f2bcde63 Check params for unsafety in THIR 2024-09-18 16:45:48 -04:00
Eric Holk
7b7992fbcf
Begin experimental support for pin reborrowing
This commit adds basic support for reborrowing `Pin` types in argument
position. At the moment it only supports reborrowing `Pin<&mut T>` as
`Pin<&mut T>` by inserting a call to `Pin::as_mut()`, and only in
argument position (not as the receiver in a method call).
2024-09-18 12:36:31 -07:00
León Orell Valerian Liehr
03e8b6bbfa
Rollup merge of #130294 - nnethercote:more-lifetimes, r=lcnr
Lifetime cleanups

The last commit is very opinionated, let's see how we go.

r? `@oli-obk`
2024-09-14 18:12:13 +02:00
Nadrieril
1f69638400 Add a machine-applicable suggestion to "unreachable pattern" 2024-09-13 21:01:29 +02:00
Nicholas Nethercote
8d32578fe1 Rename and reorder lots of lifetimes.
- Replace non-standard names like 's, 'p, 'rg, 'ck, 'parent, 'this, and
  'me with vanilla 'a. These are cases where the original name isn't
  really any more informative than 'a.
- Replace names like 'cx, 'mir, and 'body with vanilla 'a when the lifetime
  applies to multiple fields and so the original lifetime name isn't
  really accurate.
- Put 'tcx last in lifetime lists, and 'a before 'b.
2024-09-13 15:46:20 +10:00
bors
a5efa01895 Auto merge of #107251 - dingxiangfei2009:let-chain-rescope, r=jieyouxu
Rescope temp lifetime in if-let into IfElse with migration lint

Tracking issue #124085

This PR shortens the temporary lifetime to cover only the pattern matching and consequent branch of a `if let`.

At the expression location, means that the lifetime is shortened from previously the deepest enclosing block or statement in Edition 2021. This warrants an Edition change.

Coming with the Edition change, this patch also implements an edition lint to warn about the change and a safe rewrite suggestion to preserve the 2021 semantics in most cases.

Related to #103108.
Related crater runs: https://github.com/rust-lang/rust/pull/129466.
2024-09-13 03:47:30 +00:00
Stuart Cook
3ba12756d3
Rollup merge of #130235 - compiler-errors:nested-if, r=michaelwoerister
Simplify some nested `if` statements

Applies some but not all instances of `clippy::collapsible_if`. Some ended up looking worse afterwards, though, so I left those out. Also applies instances of `clippy::collapsible_else_if`

Review with whitespace disabled please.
2024-09-12 20:37:16 +10:00
Michael Goulet
954419aab0 Simplify some nested if statements 2024-09-11 13:45:23 -04:00
Ding Xiang Fei
f93df1f7dc
rescope temp lifetime in let-chain into IfElse
apply rules by span edition
2024-09-11 04:10:00 +08:00
Eduardo Sánchez Muñoz
0b20ffcb63 Remove needless returns detected by clippy in the compiler 2024-09-09 13:32:22 +02:00
Jakub Beránek
47e6b5deed Revert "Auto merge of #127537 - veluca93:struct_tf, r=BoxyUwU"
This reverts commit acb4e8b625, reversing
changes made to 100fde5246.
2024-09-01 16:35:53 +02:00
Nicholas Nethercote
c16e2899dc Add warn(unreachable_pub) to rustc_mir_build. 2024-08-29 20:13:06 +10:00
Luca Versari
7eb4cfeace Implement RFC 3525. 2024-08-28 09:54:23 +02:00
Michael Goulet
48f43fa0ed Avoid taking reference of &TyKind 2024-08-25 16:02:29 -04:00
Pavel Grigorenko
53ce92770d Fix elided_named_lifetimes in code 2024-08-24 19:21:32 +03:00
Matthias Krüger
4137f3bc15
Rollup merge of #129345 - compiler-errors:scratch4, r=jieyouxu
Use shorthand field initialization syntax more aggressively in the compiler

Caught these when cleaning up #129344 and decided to run clippy to find the rest
2024-08-21 18:15:06 +02:00
Matthias Krüger
937a18daf9
Rollup merge of #129344 - compiler-errors:less-option-unit-diagnostics, r=jieyouxu
Use `bool` in favor of `Option<()>` for diagnostics

We originally only supported `Option<()>` for optional notes/labels, but we now support `bool`. Let's use that, since it usually leads to more readable code.

I'm not removing the support from the derive macro, though I guess we could error on it... 🤔
2024-08-21 18:15:05 +02:00
Matthias Krüger
9bb17d345a
Rollup merge of #129281 - Nadrieril:tweak-unreachable-lint-wording, r=estebank
Tweak unreachable lint wording

Some tweaks to the notes added in https://github.com/rust-lang/rust/pull/128034.

r? `@estebank`
2024-08-21 18:15:03 +02:00
Michael Goulet
0b2525c787 Simplify some redundant field names 2024-08-21 01:31:42 -04:00
Michael Goulet
25ff9b6bcb Use bool in favor of Option<()> for diagnostics 2024-08-21 01:31:11 -04:00
Nadrieril
f30392a985 Move the "matches no value" note to be a span label 2024-08-20 21:53:47 +02:00
c8ef
2575196152 fix: simple typo in compiler directory 2024-08-20 20:50:32 +08:00
Nadrieril
36eced444e Cap the number of patterns pointed to by the lint 2024-08-19 21:57:40 +02:00
Nadrieril
efb28bdd90 Add a note with a link to explain empty types 2024-08-19 21:57:37 +02:00
Nadrieril
25964b541e Reword the "unreachable pattern" explanations 2024-08-19 21:39:57 +02:00
Ralf Jung
35709be02d rename AddressOf -> RawBorrow inside the compiler 2024-08-18 19:46:53 +02:00
Zalathar
194ade1267 Remove a useless ref/id/ref round-trip from pattern_from_hir
This re-lookup of `&hir::Pat` by its ID appears to be an artifact of earlier
complexity that has since been removed from the compiler.
2024-08-17 22:18:37 +10:00
bors
fbce03b195 Auto merge of #129060 - matthiaskrgr:rollup-s72gpif, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #122884 (Optimize integer `pow` by removing the exit branch)
 - #127857 (Allow to customize `// TODO:` comment for deprecated safe autofix)
 - #129034 (Add `#[must_use]` attribute to `Coroutine` trait)
 - #129049 (compiletest: Don't panic on unknown JSON-like output lines)
 - #129050 (Emit a warning instead of an error if `--generate-link-to-definition` is used with other output formats than HTML)
 - #129056 (Fix one usage of target triple in bootstrap)
 - #129058 (Add mw back to review rotation)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-14 06:43:26 +00:00
Nadrieril
249a588cad Remove a no-longer-true assert 2024-08-13 23:00:42 +02:00
Tobias Bucher
811d7dd113 #[deprecated_safe_2024]: Also use the // TODO: hint in the compiler error
This doesn't work for translated compiler error messages.
2024-08-13 11:32:47 +02:00
Tobias Bucher
399ef23d2b Allow to customize // TODO: comment for deprecated safe autofix
Relevant for the deprecation of `CommandExt::before_exit` in #125970.
2024-08-13 11:32:24 +02:00
bors
591ecb88df Auto merge of #128742 - RalfJung:miri-vtable-uniqueness, r=saethlin
miri: make vtable addresses not globally unique

Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.

To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)

r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
2024-08-13 04:32:34 +00:00
Matthias Krüger
32e0fe129d
Rollup merge of #128762 - fmease:use-more-slice-pats, r=compiler-errors
Use more slice patterns inside the compiler

Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.

r? ghost
2024-08-11 07:51:51 +02:00
Nadrieril
cd40769c02 Stabilize min_exhaustive_patterns 2024-08-10 12:07:17 +02:00
León Orell Valerian Liehr
c4c518d2d4
Use more slice patterns inside the compiler 2024-08-07 13:37:52 +02:00
Caleb Zulawski
8818c95528 Disallow enabling features without their implied features 2024-08-07 00:45:00 -04:00
Caleb Zulawski
83276f5680 Hide implicit target features from diagnostics when possible 2024-08-07 00:43:52 -04:00
Ralf Jung
5cab8ae4a4 miri: make vtable addresses not globally unique 2024-08-06 19:09:31 +02:00
Ralf Jung
212417b87f custom MIR: add support for tail calls 2024-08-05 18:23:14 +02:00
Ralf Jung
6d312d7bd1 MIR required_consts, mentioned_items: ensure we do not forget to fill these lists 2024-08-01 15:49:25 +02:00
Matthias Krüger
19f6ff0655
Rollup merge of #127159 - Nadrieril:hide-candidate, r=matthewjasper
match lowering: Hide `Candidate` from outside the lowering algorithm

The internals of `Candidate` are tricky and a source of confusion. This PR makes it so we don't expose `Candidate`s outside the lowering algorithm. Now:
- false edges are handled in `lower_match_tree`;
- `lower_match_tree` takes a list of patterns as input;
- `lower_match_tree` returns a flat datastructure that contains only the necessary information.

r? ```@matthewjasper```
2024-07-31 23:20:10 +02:00
Matthias Krüger
d73decdaad
Rollup merge of #128304 - Zalathar:thir-pat-display, r=Nadrieril
Isolate the diagnostic code that expects `thir::Pat` to be printable

Currently, `thir::Pat` implements `fmt::Display` (and `IntoDiagArg`) directly, for use by a few diagnostics.

That makes it tricky to experiment with alternate representations for THIR patterns, because the patterns currently need to be printable on their own. That immediately rules out possibilities like storing subpatterns as a `PatId` index into a central list (instead of the current directly-owned `Box<Pat>`).

This PR therefore takes an incremental step away from that obstacle, by removing `thir::Pat` from diagnostic structs in `rustc_pattern_analysis`, and hiding the pattern-printing process behind a single public `Pat::to_string` method. Doing so makes it easier to identify and update the code that wants to print patterns, and gives a place to pass in additional context in the future if necessary.

---

I'm currently not sure whether switching over to `PatId` is actually desirable or not, but I think this change makes sense on its own merits, by reducing the coupling between `thir::Pat` and the pattern-analysis error types.
2024-07-29 11:42:34 +02:00
Nadrieril
08bcc01394 Entirely hide Candidates from outside lower_match_tree 2024-07-29 10:03:32 +02:00
Nadrieril
c7471664b3 Visiting bindings is straightforward now 2024-07-29 10:03:32 +02:00
Nadrieril
cbdacec188 Abstract out the candidate manipulation not in the main algorithm 2024-07-29 09:50:07 +02:00
Nadrieril
e2fd9aa33e Set up false edges in lower_match_tree 2024-07-29 09:50:07 +02:00
Nadrieril
9e05fb67a3 Small simplification 2024-07-29 09:50:07 +02:00
Zalathar
db05b0fd34 Encapsulate the printing of WitnessPat
This hides the fact that we print `WitnessPat` by converting it to `thir::Pat`
and then printing that.
2024-07-29 14:56:50 +10:00
Nicholas Nethercote
84ac80f192 Reformat use declarations.
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
2024-07-29 08:26:52 +10:00
Zalathar
e1fc4a997d Don't store thir::Pat in error structs
In several cases this avoids the need to clone the underlying pattern, and then
print the clone later.
2024-07-28 21:58:44 +10:00
bors
355efacf0d Auto merge of #128034 - Nadrieril:explain-unreachable, r=compiler-errors
exhaustiveness: Explain why a given pattern is considered unreachable

This PR tells the user why a given pattern is considered unreachable. I reused the intersection information we were already computing; even though it's incomplete I convinced myself that it is sufficient to always get a set of patterns that cover the unreachable one.

I'm not a fan of the diagnostic messages I came up with, I'm open to suggestions.

Fixes https://github.com/rust-lang/rust/issues/127870. This is also the other one of the two diagnostic improvements I wanted to do before https://github.com/rust-lang/rust/pull/122792.

Note: the first commit is an unrelated drive-by tweak.

r? `@compiler-errors`
2024-07-26 10:51:04 +00:00
Matthias Krüger
f345c5e845
Rollup merge of #128085 - Zalathar:notes, r=Nadrieril
Various notes on match lowering

This is an assortment of comments for things that I found unclear or confusing when I was learning how match lowering works.

This PR only adds/modifies comments, so there are no functional changes.

I have tried to avoid touching code that would conflict with #127159.

r? `@Nadrieril`
2024-07-26 00:57:22 +02:00
Oli Scherer
0706cc6397 Turn an unreachable code path into an ICE 2024-07-25 15:33:34 +00:00
Zalathar
31f31aa471 Remove an obsolete comment
The test mentioned by this comment was deleted long ago by
<https://github.com/rust-lang/rust/pull/80290>.
2024-07-25 16:41:51 +10:00
Zalathar
118a70f38c Various notes on match lowering 2024-07-25 16:22:55 +10:00
Nadrieril
940769a79b Improve "covered_by_many" error 2024-07-24 08:46:52 +02:00
Nadrieril
64ac2b8082 Explain why a given pattern is considered unreachable 2024-07-24 08:02:55 +02:00
Nadrieril
bab8ede761 Move rustc-specific entrypoint to the rustc module 2024-07-24 08:02:55 +02:00
Matthias Krüger
1b4b0e9a4d
Rollup merge of #125834 - workingjubilee:weaken-thir-unsafeck-for-addr-of-static-mut, r=compiler-errors
treat `&raw (const|mut) UNSAFE_STATIC` implied deref as safe

Fixes rust-lang/rust#125833

As reported in that and related issues, `static mut STATIC_MUT: T` is very often used in embedded code, and is in many ways equivalent to `static STATIC_CELL: SyncUnsafeCell<T>`. The Rust expression of `&raw mut STATIC_MUT` and `SyncUnsafeCell::get(&STATIC_CELL)` are approximately equal, and both evaluate to `*mut T`. The library function is safe because it has *declared itself* to be safe. However, the raw ref operator is unsafe because all uses of `static mut` are considered unsafe, even though the static's value is not used by this expression (unlike, for example, `&STATIC_MUT`).

We can fix this unnatural difference by simply adding the proper exclusion for the safety check inside the THIR unsafeck, so that we do not declare it unsafe if it is not.

While the primary concern here is `static mut`, this change is made for all instances of an "unsafe static", which includes a static declared inside `extern "abi" {}`. Hypothetically, we could go as far as generalizing this to all instances of `&raw (const|mut) *ptr`, but today we do not, as we have not actually considered the range of possible expressions that use a similar encoding. We do not even extend this to thread-local equivalents, because they have less clear semantics.
2024-07-23 13:06:54 +02:00
Jubilee Young
3fdd8d5ef3 compiler: treat &raw (const|mut) UNSAFE_STATIC implied deref as safe
The implied deref to statics introduced by HIR->THIR lowering is only
used to create place expressions, it lacks unsafe semantics.
It is also confusing, as there is no visible `*ident` in the source.
For both classes of "unsafe static" (extern static and static mut)
allow this operation.

We lack a clear story around `thread_local! { static mut }`, which
is actually its own category of item that reuses the static syntax but
has its own rules. It's possible they should be similarly included, but
in the absence of a good reason one way or another, we do not bless it.
2024-07-22 14:54:36 -07:00
Trevor Gross
81135a015f
Rollup merge of #125990 - tbu-:pr_unsafe_env_lint_name, r=ehuss
Rename `deprecated_safe` lint to `deprecated_safe_2024`

Create a lint group `deprecated_safe` that includes `deprecated_safe_2024`.

Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.

r? `@ehuss`
2024-07-22 11:40:19 -05:00
Jubilee
d484654a5e
Rollup merge of #128033 - Nadrieril:explain-empty-wildcards, r=compiler-errors
Explain why we require `_` for empty patterns

This adds a note to the "non-exhaustive patterns" diagnostic to explain why we sometimes require extra `_` patterns on empty types. This is one of the two diagnostic improvements I wanted to do before [stabilizing `min_exhaustive_patterns`](https://github.com/rust-lang/rust/pull/122792).

r? ``@compiler-errors``
2024-07-21 17:44:30 -07:00
Nadrieril
8a49d83db7 Explain why we require _ for empty patterns 2024-07-21 15:24:27 +02:00
Nadrieril
710add58e2 Tweak collect_non_exhaustive_tys 2024-07-21 15:24:27 +02:00
Matthias Krüger
d846e9252c
Rollup merge of #127917 - Zalathar:after-or, r=Nadrieril
match lowering: Split `finalize_or_candidate` into more coherent methods

I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand.

This PR aims to clean up some of the confusion by:
- Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates`
- Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate`
- Taking what remains of `finalize_or_candidate`, and inlining it into its caller

---
Reviewing individual commits and ignoring whitespace is recommended.

Most of the large-looking changes are just moving existing code around, mostly unaltered.

r? ``@Nadrieril``
2024-07-20 13:24:54 +02:00
Matthias Krüger
dfee7ed13f
Rollup merge of #127556 - Zalathar:autoref, r=Nadrieril
Replace a long inline "autoref" comment with method docs

This comment has two problems:

- It is very long, making the flow of the enclosing method hard to follow.
- It starts by talking about an `autoref` flag that hasn't existed since #59114.
  - This makes it hard to trust that the information in the comment is accurate or relevant, even though much of it still seems to be true.

This PR therefore replaces the long inline comment with a revised doc comment on `bind_matched_candidate_for_guard`, and some shorter inline comments.

For readers who want more historical context, we also link to the PR that added the old comment, and the PR that removed the `autoref` flag.
2024-07-20 07:13:41 +02:00
Zalathar
239037ecde Inline finalize_or_candidate 2024-07-20 13:29:03 +10:00
Zalathar
886668cc2e Improve test_remaining_match_pairs_after_or 2024-07-20 13:29:03 +10:00
Zalathar
e60c5c1a77 Split out test_remaining_match_pairs_after_or
Only the last candidate can possibly have more match pairs, so this can be
separate from the main or-candidate postprocessing loop.
2024-07-20 12:45:12 +10:00
Zalathar
e091c356fa Improve merge_trivial_subcandidates 2024-07-20 12:45:11 +10:00
Zalathar
3b7e4bc77a Split out remove_never_subcandidates 2024-07-20 12:45:11 +10:00
Matthias Krüger
4d5ba0d2c7
Rollup merge of #127858 - Zalathar:pair-tree, r=Nadrieril
match lowering: Rename `MatchPair` to `MatchPairTree`

In #120904, `MatchPair` became able to store other match pairs as children, forming a tree. That has made the old name confusing, so this patch renames the type to `MatchPairTree`.

This PR also includes a patch renaming the `test` method to `pick_test_for_match_pair`, since it would conflict with the main change.

r? `@Nadrieril`
2024-07-18 23:05:22 +02:00
Ralf Jung
303a2db236 remove saw_const_match_error; check if pattern contains an Error instead 2024-07-18 11:58:16 +02:00
Ralf Jung
67c99d6338 avoid creating an Instance only to immediately disassemble it again 2024-07-18 11:58:16 +02:00
Ralf Jung
86ce911f90 pattern lowering: make sure we never call user-defined PartialEq instances 2024-07-18 11:58:16 +02:00
Ralf Jung
e613bc92a1 const_to_pat: cleanup leftovers from when we had to deal with non-structural constants 2024-07-18 11:58:16 +02:00
Ralf Jung
fa74a9e6aa valtree construction: keep track of which type was valtree-incompatible 2024-07-18 11:58:16 +02:00
Matthias Krüger
c98487e3be
Rollup merge of #127472 - Zalathar:block-and-unit, r=fmease
MIR building: Stop using `unpack!` for `BlockAnd<()>`

This is a subset of #127416, containing only the parts related to `BlockAnd<()>`.

The first patch removes the non-assigning form of the `unpack!` macro, because it is frustratingly inconsistent with the main form. We can replace it with an ordinary method that discards the `()` and returns the block.

The second patch then finds all of the remaining code that was using `unpack!` with `BlockAnd<()>`, and updates it to use that new method instead.

---

Changes since original review of #127416:
- Renamed `fn unpack_block` → `fn into_block`
- Removed `fn unpack_discard`, replacing it with `let _: BlockAnd<()> = ...` (2 occurrences)
- Tweaked `arm_end_blocks` to unpack earlier and build `Vec<BasicBlock>` instead of `Vec<BlockAnd<()>>`
2024-07-17 16:22:28 +02:00
Tobias Bucher
bf96c56e84 Rename deprecated_safe lint to deprecated_safe_2024
Create a lint group `deprecated_safe` that includes
`deprecated_safe_2024`.

Addresses https://github.com/rust-lang/rust/issues/124866#issuecomment-2142814375.
2024-07-17 14:39:56 +02:00
Zalathar
411fcb6b2d Rename test to pick_test_for_match_pair 2024-07-17 21:50:12 +10:00
Zalathar
03bfa3690e Rename MatchPair to MatchPairTree
In #120904, `MatchPair` became able to store other match pairs as children,
forming a tree. That has made the old name confusing, so this patch renames the
type to `MatchPairTree`.
2024-07-17 21:50:07 +10:00
Matthias Krüger
7409a5281d
Rollup merge of #127707 - Zalathar:expand-until, r=Nadrieril
match lowering: Use an iterator to find `expand_until`

A small cleanup that I noticed while looking at #127164.

This makes it easier to see that the split point is always the index after the found item, or the whole list if no stopping point was found.

r? `@Nadrieril`
2024-07-16 18:09:09 +02:00
Trevor Gross
47600074fe
Rollup merge of #127709 - Zalathar:pair-mod, r=Nadrieril
match lowering: Move `MatchPair` tree creation to its own module

This makes it easier to see that `MatchPair::new` has only one non-recursive caller, because the recursive callers are all in this module. No functional changes.

---

I have used `git diff --color-moved` to verify that the moved code is identical to the old code, except for reduced visibility on the helper methods.
2024-07-16 02:02:24 -05:00
Zalathar
e37b92ffd8 Use an iterator to find expand_until
This makes it easier to see that the split point is always the index after the
found item, or the whole list if no stopping point was found.
2024-07-16 11:51:52 +10:00
Adwin White
e595f3d13f Add cache for allocate_str 2024-07-14 22:11:46 +08:00
Zalathar
f7508f8816 Improve internal docs for MatchPair 2024-07-14 15:01:02 +10:00
Zalathar
ce86b2ae96 Move MatchPair tree creation to its own module
This makes it easier to see that `MatchPair::new` has only one non-recursive
caller, because the recursive callers are all in this module.
2024-07-14 15:00:57 +10:00
Zalathar
83e1efb254 Replace a long inline "autoref" comment with method docs
This comment has two problems:

- It is very long, making the flow of the enclosing method hard to follow.
- It starts by talking about an `autoref` flag that hasn't existed since #59114.

This PR therefore replaces the long inline comment with a revised doc comment
on `bind_matched_candidate_for_guard`, and some shorter inline comments.

For readers who want more historical context, we also link to the PR that added
the old comment, and the PR that removed the `autoref` flag.
2024-07-10 20:25:54 +10:00
Nadrieril
42772e98e0 Address review comments 2024-07-09 22:47:35 +02:00
Nadrieril
3e030b38ef Return the otherwise_block instead of passing it as argument
This saves a few blocks and matches the common `unpack!` paradigm.
2024-07-09 22:47:35 +02:00
Nadrieril
fc40247c6b Factor out the "process remaining candidates" cases 2024-07-09 22:47:35 +02:00
Nadrieril
8a222ffd6b Don't try to save an extra block
This is preparation for the next commit.
2024-07-09 22:47:35 +02:00
Nadrieril
c5062f7318 Move or-pattern expansion inside the main part of the algorithm 2024-07-09 22:47:35 +02:00
Nadrieril
bff4d213fa Factor out the special handling of or-patterns 2024-07-09 22:47:35 +02:00
Nadrieril
5bf50e66f9 Move a function 2024-07-09 22:47:35 +02:00
bors
9dcaa7f92c Auto merge of #127028 - Nadrieril:fix-or-pat-expansion, r=matthewjasper
Fix regression in the MIR lowering of or-patterns

In https://github.com/rust-lang/rust/pull/126553 I made a silly indexing mistake and regressed the MIR lowering of or-patterns. This fixes it.

r? `@compiler-errors` because I'd like this to be merged quickly 🙏
2024-07-09 16:33:59 +00:00
bors
9af6fee87d Auto merge of #113128 - WaffleLapkin:become_trully_unuwuable, r=oli-obk,RalfJung
Support tail calls in mir via `TerminatorKind::TailCall`

This is one of the interesting bits in tail call implementation — MIR support.

This adds a new `TerminatorKind` which represents a tail call:
```rust
    TailCall {
        func: Operand<'tcx>,
        args: Vec<Operand<'tcx>>,
        fn_span: Span,
    },
```

*Structurally* this is very similar to a normal `Call` but is missing a few fields:
- `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call)
- `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do
- `unwind` — I _think_ this is applicable too, although it's a bit confusing
- `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now)

It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too.

-----

There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':)

-----

r? `@oli-obk`
cc `@scottmcm` `@DrMeepster` `@JakobDegen`
2024-07-08 04:35:04 +00:00
Zalathar
1cf4eb2ad2 Stop using unpack! for BlockAnd<()> 2024-07-08 12:05:41 +10:00
Zalathar
4fe8dd05ed Remove the non-assigning form of unpack!
This kind of unpacking can be expressed as an ordinary method on
`BlockAnd<()>`.
2024-07-08 12:04:09 +10:00
Maybe Lapkin
7fd0c55a1a Fix conflicts after rebase
- r-l/r 126784
- r-l/r 127113
- r-l/miri 3562
2024-07-07 18:16:38 +02:00
Maybe Waffle
5f4caae11c Fix unconditional recursion lint wrt tail calls 2024-07-07 17:11:05 +02:00
DrMeepster
4187cdc013 Properly handle drops for tail calls 2024-07-07 17:11:05 +02:00
Maybe Waffle
484152d562 Support tail calls in mir via TerminatorKind::TailCall 2024-07-07 17:11:04 +02:00
Zalathar
f095de4bf1 coverage: Rename mir::coverage::BranchInfo to CoverageInfoHi
This opens the door to collecting and storing coverage information that is
unrelated to branch coverage or MC/DC.
2024-07-05 13:53:05 +10:00
bors
c872a1418a Auto merge of #125507 - compiler-errors:type-length-limit, r=lcnr
Re-implement a type-size based limit

r? lcnr

This PR reintroduces the type length limit added in #37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in #72412, which caused the `walk` function to no longer walk over identical elements.

Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode).

This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired.

Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future.

Fixes #125460
2024-07-03 11:56:36 +00:00
Michael Goulet
b1059ccda2 Instance::resolve -> Instance::try_resolve, and other nits 2024-07-02 17:28:03 -04:00
hattizai
ada9fda7c3 chore: remove duplicate words 2024-07-02 11:25:31 +08:00
Zalathar
ed07712e96 Replace a magic boolean with enum ScheduleDrops 2024-06-30 19:02:25 +10:00
Zalathar
3b22589cfa Replace a magic boolean with enum EmitStorageLive
The previous boolean used `true` to indicate that storage-live should _not_ be
emitted, so all occurrences of `Yes` and `No` should be the logical opposite of
the previous value.
2024-06-30 18:55:39 +10:00
Zalathar
ad575b093b Replace a magic boolean with enum DeclareLetBindings
The new enum `DeclareLetBindings` has three variants:
- `Yes`: Declare `let` bindings as normal, for `if` conditions.
- `No`: Don't declare bindings, for match guards and let-else.
- `LetNotPermitted`: Assert that `let` expressions should not occur.
2024-06-30 18:55:39 +10:00
Matthias Krüger
806c5c1971
Rollup merge of #126835 - Nadrieril:reify-decision-tree, r=matthewjasper
Simplifications in match lowering

A series of small simplifications and deduplications in the MIR lowering of patterns.

r? ````@matthewjasper````
2024-06-29 09:14:56 +02:00
Nadrieril
834f043a08 Fix expansion of or-patterns 2024-06-27 11:26:34 +02:00
Matthias Krüger
7e1489cf63
Rollup merge of #126932 - Zalathar:flat-pat, r=Nadrieril
Tweak `FlatPat::new` to avoid a temporarily-invalid state

It was somewhat confusing that the old constructor would create a `FlatPat` in a (possibly) non-simplified state, and then simplify its contents in-place.

So instead we now create its fields as local variables, perform simplification, and then create the struct afterwards.

This doesn't affect correctness, but is less confusing.

---

I've also included some semi-related comments that I made while trying to navigate this code.
2024-06-25 21:33:44 +02:00
Matthias Krüger
6077c0ed9d
Rollup merge of #126926 - Zalathar:candidate-per-arm, r=Nadrieril
Tweak a confusing comment in `create_match_candidates`

This comment was accurate at the time it was written, but various later changes reshuffled things in ways that caused the existing comment to become confusing.

I've therefore tried to clarify that *these* candidates are 1:1 with match arms, while also warning that that isn't the case in general.
2024-06-25 21:33:43 +02:00
Zalathar
c2f1072e01 Tweak FlatPat::new to avoid a temporarily-invalid state
It was somewhat confusing that the old constructor would create a `FlatPat` in
a (possibly) non-simplified state, and then simplify its contents in-place.

So instead we now create its fields as local variables, perform simplification,
and then create the struct afterwards.

This doesn't affect correctness, but is less confusing.
2024-06-25 17:46:35 +10:00
Zalathar
8016940ef4 Tweak a confusing comment in create_match_candidates 2024-06-25 12:16:49 +10:00
bors
5b270e1198 Auto merge of #126813 - compiler-errors:SliceLike, r=lcnr
Add `SliceLike` to `rustc_type_ir`, use it in the generic solver code (+ some other changes)

First, we split out `TraitRef::new_from_args` which takes *just* `ty::GenericArgsRef` from `TraitRef::new` which takes `impl IntoIterator<Item: Into<GenericArg>>`. I will explain in a minute why.

Second, we introduce `SliceLike`, which allows us to be generic over `List<T>` and `[T]`. This trait has an `as_slice()` and `into_iter()` method, and some other convenience functions. However, importantly, since types like `I::GenericArgs` now implement `SliceLike` rather than `IntoIter<Item = I::GenericArg>`, we can't use `TraitRef::new` on this directly. That's where `new_from_args` comes in.

Finally, we adjust all the code to use these slice operators. Some things get simpler, some things get a bit more annoying since we need to use `as_slice()` in a few places. 🤷

r? lcnr
2024-06-25 00:33:49 +00:00
bors
d8d5732456 Auto merge of #126784 - scottmcm:smaller-terminator, r=compiler-errors
Save 2 pointers in `TerminatorKind` (96 → 80 bytes)

These things don't need to be `Vec`s; boxed slices are enough.

The frequent one here is call arguments, but MIR building knows the number of arguments from the THIR, so the collect is always getting the allocation right in the first place, and thus this shouldn't ever add the shrink-in-place overhead.
2024-06-24 19:22:01 +00:00
Michael Goulet
f26cc349d9 Split out IntoIterator and non-Iterator constructors for AliasTy/AliasTerm/TraitRef/projection 2024-06-24 11:28:21 -04:00
Trevor Gross
6fb6c19c96 Replace f16 and f128 pattern matching stubs with real implementations
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.

This also fixes some missing range and match handling in `rustc_middle`.
2024-06-23 04:28:42 -05:00
Nadrieril
beb1d35d7d Change comment to reflect switch to THIR unsafeck 2024-06-22 19:06:40 +02:00
Nadrieril
ff49c3769b Reuse lower_let_expr for let .. else lowering 2024-06-22 19:05:50 +02:00
Nadrieril
7b150a161e Don't use fake wildcards when we can get the failure block directly
This commit too was obtained by repeatedly inlining and simplifying.
2024-06-22 19:05:48 +02:00
Scott McMurray
b28efb11af Save 2 pointers in TerminatorKind (96 → 80 bytes)
These things don't need to be `Vec`s; boxed slices are enough.

The frequent one here is call arguments, but MIR building knows the number of arguments from the THIR, so the collect is always getting the allocation right in the first place, and thus this shouldn't ever add the shrink-in-place overhead.
2024-06-21 18:02:05 -07:00
Michael Goulet
ffd72b1700 Fix remaining cases 2024-06-21 19:00:18 -04:00
Scott McMurray
55d13379ac [GVN] Add tests for generic pointees with PtrMetadata 2024-06-20 22:16:59 -07:00
Nadrieril
c0c6c32a45 Move lower_match_tree 2024-06-19 23:31:22 +02:00
Nadrieril
878ccd22fa There's nothing to bind for a wildcard
This commit was obtained by repeatedly inlining and simplifying.
2024-06-19 23:31:22 +02:00
Nadrieril
cef49f73e7 Small dedup 2024-06-19 23:31:22 +02:00
Nadrieril
012626b32b Only one caller of lower_match_tree was using the fake borrows 2024-06-19 23:31:22 +02:00
Nadrieril
ea29d6ad0b We can traverse bindings before lower_match_tree now 2024-06-19 23:31:22 +02:00
bors
3186d17d56 Auto merge of #126679 - fmease:rollup-njrv2py, r=fmease
Rollup of 6 pull requests

Successful merges:

 - #125447 (Allow constraining opaque types during subtyping in the trait system)
 - #125766 (MCDC Coverage: instrument last boolean RHS operands from condition coverage)
 - #125880 (Remove `src/tools/rust-demangler`)
 - #126154 (StorageLive: refresh storage (instead of UB) when local is already live)
 - #126572 (override user defined channel when using precompiled rustc)
 - #126662 (Unconditionally warn on usage of `wasm32-wasi`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-19 11:09:31 +00:00
León Orell Valerian Liehr
a7cf6ece62
Rollup merge of #125766 - RenjiSann:fresh-mcdc-branch-on-bool, r=nnethercote
MCDC Coverage: instrument last boolean RHS operands from condition coverage

Fresh PR from #124652

--

This PR ensures that the top-level boolean expressions that are not part of the control flow are correctly instrumented thanks to condition coverage.

See discussion on https://github.com/rust-lang/rust/issues/124120.
Depends on `@Zalathar` 's condition coverage implementation #125756.
2024-06-19 13:04:57 +02:00
León Orell Valerian Liehr
e111e99253
Rollup merge of #126553 - Nadrieril:expand-or-pat-into-above, r=matthewjasper
match lowering: expand or-candidates mixed with candidates above

This PR tweaks match lowering of or-patterns. Consider this:
```rust
match (x, y) {
    (1, true) => 1,
    (2, false) => 2,
    (1 | 2, true | false) => 3,
    (3 | 4, true | false) => 4,
    _ => 5,
}
```
One might hope that this can be compiled to a single `SwitchInt` on `x` followed by some boolean checks. Before this PR, we compile this to 3 `SwitchInt`s on `x`, because an arm that contains more than one or-pattern was compiled on its own. This PR groups branch `3` with the two branches above, getting us down to 2 `SwitchInt`s on `x`.

We can't in general expand or-patterns freely, because this interacts poorly with another optimization we do: or-pattern simplification. When an or-pattern doesn't involve bindings, we branch the success paths of all its alternatives to the same block. The drawback is that in a case like:
```rust
match (1, true) {
    (1 | 2, false) => unreachable!(),
    (2, _) => unreachable!(),
    _ => {}
}
```
if we used a single `SwitchInt`, by the time we test `false` we don't know whether we came from the `1` case or the `2` case, so we don't know where to go if `false` doesn't match.

Hence the limitation: we can process or-pattern alternatives alongside candidates that precede it, but not candidates that follow it. (Unless the or-pattern is the only remaining match pair of its candidate, in which case we can process it alongside whatever).

This PR allows the processing of or-pattern alternatives alongside candidates that precede it. One benefit is that we now process or-patterns in a single place in `mod.rs`.

r? ``@matthewjasper``
2024-06-19 09:52:00 +02:00
Dorian Péron
6c7c824767 coverage: Make MCDC take in account last RHS of condition-coverage
Condition coverage extends branch coverage to treat the specific case
of last operands of boolean decisions not involved in control flow.
This is ultimately made for MCDC to be exhaustive on all boolean expressions.

This patch adds a call to `visit_branch_coverage_operation` to track the
top-level operand of the said decisions, and changes
`visit_coverage_standalone_condition` so MCDC branch registration is called
when enabled on these _last RHS_ cases.
2024-06-19 07:41:51 +00:00
Oli Scherer
3f34196839 Remove redundant argument from subdiagnostic method 2024-06-18 15:42:11 +00:00
Oli Scherer
7ba82d61eb Use a dedicated type instead of a reference for the diagnostic context
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
2024-06-18 15:42:11 +00:00
Nadrieril
7b764be9f1 Expand or-candidates mixed with candidates above
We can't mix them with candidates below them, but we can mix them with
candidates above.
2024-06-16 18:39:50 +02:00
Nadrieril
ce374fcbc1 Factor out finalize_or_candidate 2024-06-16 18:33:23 +02:00
Nadrieril
764f086f2c Use otherwise_block for or-pattern shortcutting 2024-06-16 18:30:26 +02:00
Nadrieril
5fe2ca65cf Always set otherwise_blocks 2024-06-16 18:27:24 +02:00
Nadrieril
e74b30e3a9 Tweak simple or-pattern expansion 2024-06-16 18:23:51 +02:00
Matthias Krüger
335e320baa
Rollup merge of #126354 - compiler-errors:variance, r=lcnr
Use `Variance` glob imported variants everywhere

Fully commit to using the globbed variance. Could be convinced the other way, and change this PR to not use the globbed variants anywhere, but I'd rather we do one or the other.

r? lcnr
2024-06-15 10:56:40 +02:00
Michael Goulet
93ff86ed7c Use is_lang_item more aggressively 2024-06-14 16:54:29 -04:00
Michael Goulet
54fa4b0b74 Use Variance glob import everywhere 2024-06-12 16:25:45 -04:00
Tobias Bucher
4f5fb3126f Add TODO comment to unsafe env modification
Addresses https://github.com/rust-lang/rust/pull/124636#issuecomment-2132119534.

I think that the diff display regresses a little, because it's no longer
showing the `+` to show where the `unsafe {}` is added. I think it's
still fine.
2024-06-12 17:51:18 +02:00
Nicholas Nethercote
75b164d836 Use tidy to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
  `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
  sometimes the order is alphabetical, and sometimes there is no
  particular order.
- Sometimes the attributes of a particular kind aren't even grouped
  all together, e.g. there might be a `feature`, then an `allow`, then
  another `feature`.

This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
  because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
  ignored in `rustfmt.toml`).
2024-06-12 15:49:10 +10:00
Matthias Krüger
2d7f7ffba5
Rollup merge of #126159 - RalfJung:scalarint-size-mismatch, r=oli-obk
ScalarInt: size mismatches are a bug, do not delay the panic

Cc [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Why.20are.20ScalarInt.20to.20iN.2FuN.20methods.20fallible.3F)

r? ``@oli-obk``
2024-06-10 21:12:25 +02:00
Ralf Jung
3c57ea0df7 ScalarInt: size mismatches are a bug, do not delay the panic 2024-06-10 13:43:16 +02:00
Nicholas Nethercote
29629d0075 Remove some unused crate dependencies.
I found these by setting the `unused_crate_dependencies` lint
temporarily to `Warn`.
2024-06-10 19:55:49 +10:00
Oli Scherer
cbee17d502 Revert "Create const block DefIds in typeck instead of ast lowering"
This reverts commit ddc5f9b6c1.
2024-06-07 08:33:58 +00:00
bors
2d28b6384e Auto merge of #124482 - spastorino:unsafe-extern-blocks, r=oli-obk
Unsafe extern blocks

This implements RFC 3484.

Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484

This is better reviewed commit by commit.
2024-06-06 08:14:58 +00:00