bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity
287067 commits 17 branches 0 tags 545 MiB
Commit graph

136 commits

Author SHA1 Message Date
bors
8bf5a8d12f Auto merge of #132833 - est31:stabilize_let_chains, r=fee1-dead 
Stabilize let chains in the 2024 edition

# Stabilization report

This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust.

[tracking issue]: https://github.com/rust-lang/rust/issues/53667
[RFC 2497]: https://github.com/rust-lang/rfcs/pull/2497
[2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html

## What is being stabilized

The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable.

```Rust
struct FnCall<'a> {
    fn_name: &'a str,
    args: Vec<i32>,
}

fn is_legal_ident(s: &str) -> bool {
    s.chars()
        .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c))
}

impl<'a> FnCall<'a> {
    fn parse(s: &'a str) -> Option<Self> {
        if let Some((fn_name, after_name)) = s.split_once("(")
            && !fn_name.is_empty()
            && is_legal_ident(fn_name)
            && let Some((args_str, "")) = after_name.rsplit_once(")")
        {
            let args = args_str
                .split(',')
                .map(|arg| arg.parse())
                .collect::<Result<Vec<_>, _>>();
            args.ok().map(|args| FnCall { fn_name, args })
        } else {
            None
        }
    }
    fn exec(&self) -> Option<i32> {
        let iter = self.args.iter().copied();
        match self.fn_name {
            "sum" => Some(iter.sum()),
            "max" => iter.max(),
            "min" => iter.min(),
            _ => None,
        }
    }
}

fn main() {
    println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec());
    println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec());
}
```

The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition.

closes #53667

## Why 2024 edition?

Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords.

In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`].

In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function.

[generate correct MIR]: https://github.com/rust-lang/rust/issues/104843
[stay consistent with `if let`]: https://github.com/rust-lang/rust/pull/103293#issuecomment-1293408574
[drop order changes]: https://github.com/rust-lang/rust/issues/124085

## Introduction considerations

As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below.

## Implementation history

* History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted.
* https://github.com/rust-lang/rust/pull/94927
* https://github.com/rust-lang/rust/pull/94951
* https://github.com/rust-lang/rust/pull/94974
* https://github.com/rust-lang/rust/pull/95008
* https://github.com/rust-lang/rust/pull/97295
* https://github.com/rust-lang/rust/pull/98633
* https://github.com/rust-lang/rust/pull/99731
* https://github.com/rust-lang/rust/pull/102394
* https://github.com/rust-lang/rust/pull/100526
* https://github.com/rust-lang/rust/pull/100538
* https://github.com/rust-lang/rust/pull/102998
* https://github.com/rust-lang/rust/pull/103405
* https://github.com/rust-lang/rust/pull/103293
* https://github.com/rust-lang/rust/pull/107251
* https://github.com/rust-lang/rust/pull/110568
* https://github.com/rust-lang/rust/pull/115677
* https://github.com/rust-lang/rust/pull/117743
* https://github.com/rust-lang/rust/pull/117770
* https://github.com/rust-lang/rust/pull/118191
* https://github.com/rust-lang/rust/pull/119554
* https://github.com/rust-lang/rust/pull/129394
* https://github.com/rust-lang/rust/pull/132828
* https://github.com/rust-lang/reference/pull/1179
* https://github.com/rust-lang/reference/pull/1251
* https://github.com/rust-lang/rustfmt/pull/5910

[original stabilization PR]: https://github.com/rust-lang/rust/pull/94927

## Adoption history

### In the compiler

* History before March 14, 2022 can be found in the [original stabilization PR].
* https://github.com/rust-lang/rust/pull/115983
* https://github.com/rust-lang/rust/pull/116549
* https://github.com/rust-lang/rust/pull/116688

### Outside of the compiler

* https://github.com/rust-lang/rust-clippy/pull/11750
* [rspack](https://github.com/web-infra-dev/rspack)
* [risingwave](https://github.com/risingwavelabs/risingwave)
* [dylint](https://github.com/trailofbits/dylint)
* [convex-backend](https://github.com/get-convex/convex-backend)
* [tikv](https://github.com/tikv/tikv)
* [Daft](https://github.com/Eventual-Inc/Daft)
* [greptimedb](https://github.com/GreptimeTeam/greptimedb)

## Tests

<details>

### Intentional restrictions

[`partially-macro-expanded.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand.
[`parens.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains
[`ensure-that-let-else-does-not-interact-with-let-chains.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining.

### Overlap with match guards

[`move-guard-if-let-chain.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let`
[`shadowing.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected
[`ast-validate-guards.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate

### Simple cases from the early days

PR #88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs.

[`then-else-blocks.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs)
[`ast-lowering-does-not-wrap-let-chains.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs)
[`issue-90722.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs)
[`issue-92145.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs)

### Drop order/MIR scoping tests

[`issue-100276.rs`](4adafcf40a/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes
[`drop_order.rs`](4adafcf40a/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains
[`scope.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test
[`drop-scope.rs`](4adafcf40a/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm
[`drop_order_if_let_rescope.rs`](4adafcf40a/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains
[`mir_let_chains_drop_order.rs`](4adafcf40a/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024.
[`issue-99938.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](4adafcf40a/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by #102394

### Linting

[`irrefutable-lets.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`.
[`issue-121070-let-range.rs`](4adafcf40a/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here

### Parser: intentional restrictions

[`disallowed-positions.rs`](2128d8df0e/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level
[`invalid-let-in-a-valid-let-context.rs`](4adafcf40a/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`).

### Parser: recovery

[`issue-103381.rs`](4adafcf40a/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let`
[`semi-in-let-chain.rs`](4adafcf40a/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s)
[`deli-ident-issue-1.rs`](4adafcf40a/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](4adafcf40a/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints

### Misc

[`conflicting_bindings.rs`](4adafcf40a/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well.
[`let-chains-attr.rs`](4adafcf40a/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains

### Tangential tests with `#![feature(let_chains)]`

[`if-let.rs`](4adafcf40a/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains
[`logical_or_in_conditional.rs`](4adafcf40a/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||`
[`stringify.rs`](4adafcf40a/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro
[`expanded-interpolation.rs`](4adafcf40a/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](4adafcf40a/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty`
[`diverges-not.rs`](4adafcf40a/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains

</details>

## Possible future work

* There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax.
  * https://github.com/rust-lang/lang-team/issues/297
* One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly.
* Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work).

[RFC 3573]: https://github.com/rust-lang/rfcs/pull/3573
[`if_let_guard` tracking issue]: https://github.com/rust-lang/rust/issues/51114

## Open questions / blockers

- [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [#117977](https://github.com/rust-lang/rust/issues/117977)
- [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [#103476](https://github.com/rust-lang/rust/issues/103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in #133093
- [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093
- [x] Parsing rejection tests: addressed by https://github.com/rust-lang/rust/pull/132828
- [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): https://github.com/rust-lang/rust/pull/139456
- [x] https://github.com/rust-lang/rust/issues/86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`.
- [x] Documentation in the reference: https://github.com/rust-lang/reference/pull/1740
- [x] Add chapter to the Rust 2024 [edition guide]: https://github.com/rust-lang/edition-guide/pull/337
- [x] Resolve open questions on desired drop order.

[original reference PR]: https://github.com/rust-lang/reference/pull/1179
[edition guide]: https://github.com/rust-lang/edition-guide
 2025-04-22 07:54:10 +00:00
est31
162daaa2fa Remove let_chains feature gate from even more tests 2025-04-18 15:57:29 +02:00
Michael Goulet
3ee62a906e Do not optimize out SwitchInt before borrowck, or if Zmir-preserve-ub 2025-04-08 21:05:20 +00:00
Zalathar
7805b465fd Split visit_primary_bindings into two variants 
The existing method does some non-obvious extra work to collect user types and
build user-type projections, which is specifically needed by `declare_bindings`
and not by the other two callers.
 2025-03-16 12:10:35 +11:00
Zalathar
bca5f567d2 Add a mir-opt test that demonstrates user type annotations 2025-03-16 12:10:35 +11:00
许杰友 Jieyou Xu (Joe)
def44600d1
Rollup merge of #135964 - ehuss:cenum_impl_drop_cast, r=Nadrieril 
Make cenum_impl_drop_cast a hard error

This changes the `cenum_impl_drop_cast` lint to be a hard error. This lint has been deny-by-default and warning in dependencies since https://github.com/rust-lang/rust/pull/97652 about 2.5 years ago.

Closes https://github.com/rust-lang/rust/issues/73333
 2025-02-05 19:09:33 +08:00
Michael Goulet
eeecb56b73 Represent the raw pointer for a array length check as a new kind of fake borrow 2025-01-28 00:00:33 +00:00
Michael Goulet
057313b7a6 Reapply "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, r=davidtwco,RalfJung" 
This reverts commit 122a55bb44.
 2025-01-27 23:42:47 +00:00
Eric Huss
e0bbeb7a00 Make cenum_impl_drop_cast a hard error 
This changes the `cenum_impl_drop_cast` lint to be a hard error. This
lint has been deny-by-default and warning in dependencies since
https://github.com/rust-lang/rust/pull/97652 about 2.5 years ago.

Closes https://github.com/rust-lang/rust/issues/73333
 2025-01-23 16:45:19 -08:00
Rémy Rakic
122a55bb44 Revert "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, r=davidtwco,RalfJung" 
This reverts commit b57d93d8b9, reversing
changes made to 0aeaa5eb22.
 2025-01-18 22:09:35 +00:00
Rémy Rakic
ca1c17c88d Revert "Auto merge of #134330 - scottmcm:no-more-rvalue-len, r=matthewjasper" 
This reverts commit e108481f74, reversing
changes made to 303e8bd768.
 2025-01-18 22:09:34 +00:00
Oli Scherer
15c01eb22c Fix cycle error only occurring with -Zdump-mir 2025-01-10 08:57:54 +00:00
Ralf Jung
ac9cb908ac turn rustc_box into an intrinsic 2025-01-03 12:01:31 +01:00
Scott McMurray
5ba54c9e31 Delete Rvalue::Len 
Everything's moved to `PtrMetadata` instead.
 2024-12-22 06:12:39 -08:00
Scott McMurray
612adbb6bf Bounds-check with PtrMetadata instead of Len in MIR 2024-12-03 11:05:45 -08:00
Camille GILLOT
c76f1f0b9b Doc comment custom MIR debuginfo. 
and add a test for the constant case
 2024-11-29 12:32:55 +01:00
lcnr
6cf4cb8484 bless mir-opt tests 2024-10-17 10:22:55 +02:00
Lukas Markeffsky
bd31e3ed70 be even more precise about "cast" vs "coercion" 2024-09-24 23:12:02 +02:00
Matthias Krüger
08187c32c7
Rollup merge of #129664 - adetaylor:arbitrary-self-types-pointers-feature-gate, r=wesleywiser 
Arbitrary self types v2: pointers feature gate.

The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are:

* _do_ support `self` types which can't safely implement `Deref`
* do _not_ support generic `self` types
* do _not_ support raw pointers as `self` types.

This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes.

For now, this can be resolved by adding the new
`arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate.

[Tracking issue](https://github.com/rust-lang/rust/issues/44874)

This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
 2024-09-05 03:47:42 +02:00
Camille GILLOT
f68f66538a Create opaque definitions in resolver. 2024-08-31 20:14:43 +00:00
Adrian Taylor
e77eb042ce Arbitrary self types v2: pointers feature gate. 
The main `arbitrary_self_types` feature gate will shortly be reused for
a new version of arbitrary self types which we are amending per [this
RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md).
The main amendments are:

* _do_ support `self` types which can't safely implement `Deref`
* do _not_ support generic `self` types
* do _not_ support raw pointers as `self` types.

This PR relates to the last of those bullet points: this strips pointer
support from the current `arbitrary_self_types` feature.
We expect this to cause some amount of breakage for crates using this
unstable feature to allow raw pointer self types. If that's the case, we
want to know about it, and we want crate authors to know of the upcoming
changes.

For now, this can be resolved by adding the new
`arbitrary_self_types_pointers` feature to such crates. If we determine
that use of raw pointers as self types is common, then we may maintain
that as an unstable feature even if we come to stabilize the rest of the
`arbitrary_self_types` support in future. If we don't hear that this PR
is causing breakage, then perhaps we don't need it at all, even behind
an unstable feature gate.

[Tracking issue](https://github.com/rust-lang/rust/issues/44874)

This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
 2024-08-27 17:32:35 +00:00
Scott McMurray
99cb0c6bc3 Bless *all* the mir-opt tests 2024-08-18 16:07:33 -07:00
Scott McMurray
249a36ffbd Update mir-opt filechecks 2024-08-18 15:52:23 -07:00
Nadrieril
99468bb760 Update tests 2024-08-10 12:07:17 +02:00
Ralf Jung
212417b87f custom MIR: add support for tail calls 2024-08-05 18:23:14 +02:00
Nadrieril
e2fd9aa33e Set up false edges in lower_match_tree 2024-07-29 09:50:07 +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
8a222ffd6b Don't try to save an extra block 
This is preparation for the next commit.
 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
Nadrieril
834f043a08 Fix expansion of or-patterns 2024-06-27 11:26:34 +02:00
Nadrieril
5df6f72057 Add test 2024-06-27 11:26:34 +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
Michael Goulet
0fc18e3a17 Remove DebugWithInfcx 2024-06-11 22:13:04 -04:00
Scott McMurray
a4d0fc39ba Add SingleUseConsts mir-opt pass 2024-06-10 00:06:02 -07: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
Nicholas Nethercote
c9c80d2c5f rustfmt tests/mir-opt. 
The only non-obvious changes:
- `building/storage_live_dead_in_statics.rs` has a `#[rustfmt::skip]`
  attribute to avoid reformating a table of data.
- Two `.mir` files have slight changes involving line numbers.
- In `unusual_item_types.rs` an `EMIT_MIR` annotation is moved to
  outside a function, which is the usual spot, because `tidy` complains
  if such a comment is indented.

The commit also tweaks the comments in `rustfmt.toml`.
 2024-06-03 14:17:16 +10:00
Nicholas Nethercote
ac24299636 Reformat mir! macro invocations to use braces. 
The `mir!` macro has multiple parts:
- An optional return type annotation.
- A sequence of zero or more local declarations.
- A mandatory starting anonymous basic block, which is brace-delimited.
- A sequence of zero of more additional named basic blocks.

Some `mir!` invocations use braces with a "block" style, like so:
```
mir! {
    let _unit: ();
    {
	let non_copy = S(42);
	let ptr = std::ptr::addr_of_mut!(non_copy);
	// Inside `callee`, the first argument and `*ptr` are basically
	// aliasing places!
	Call(_unit = callee(Move(*ptr), ptr), ReturnTo(after_call), UnwindContinue())
    }
    after_call = {
	Return()
    }
}
```
Some invocations use parens with a "block" style, like so:
```
mir!(
    let x: [i32; 2];
    let one: i32;
    {
	x = [42, 43];
	one = 1;
	x = [one, 2];
	RET = Move(x);
	Return()
    }
)
```
And some invocations uses parens with a "tighter" style, like so:
```
mir!({
    SetDiscriminant(*b, 0);
    Return()
})
```
This last style is generally used for cases where just the mandatory
starting basic block is present. Its braces are placed next to the
parens.

This commit changes all `mir!` invocations to use braces with a "block"
style. Why?

- Consistency is good.

- The contents of the invocation is a block of code, so it's odd to use
  parens. They are more normally used for function-like macros.

- Most importantly, the next commit will enable rustfmt for
  `tests/mir-opt/`. rustfmt is more aggressive about formatting macros
  that use parens than macros that use braces. Without this commit's
  changes, rustfmt would break a couple of `mir!` macro invocations that
  use braces within `tests/mir-opt` by inserting an extraneous comma.
  E.g.:
  ```
  mir!(type RET = (i32, bool);, { // extraneous comma after ';'
      RET.0 = 1;
      RET.1 = true;
      Return()
  })
  ```
  Switching those `mir!` invocations to use braces avoids that problem,
  resulting in this, which is nicer to read as well as being valid
  syntax:
  ```
  mir! {
      type RET = (i32, bool);
      {
	  RET.0 = 1;
	  RET.1 = true;
	  Return()
      }
  }
  ```
 2024-06-03 13:24:44 +10:00
Scott McMurray
7150839552 Add custom mir support for PtrMetadata 2024-05-28 09:28:51 -07:00
Oli Scherer
ddc5f9b6c1 Create const block DefIds in typeck instead of ast lowering 2024-05-28 13:38:43 +00:00
Scott McMurray
95c0e5c6a8 Remove Rvalue::CheckedBinaryOp 2024-05-17 20:33:02 -07:00
bors
0f40f14b61 Auto merge of #123332 - Nadrieril:testkind-never, r=matthewjasper 
never patterns: lower never patterns to `Unreachable` in MIR

This lowers a `!` pattern to "goto Unreachable". Ideally I'd like to read from the place to make it clear that the UB is coming from an invalid value, but that's tricky so I'm leaving it for later.

r? `@compiler-errors` how do you feel about a lil bit of MIR lowering
 2024-05-07 15:14:20 +00:00
Nadrieril
57e8aebb6c Lower never patterns to Unreachable in mir 2024-05-04 16:30:01 +02:00
Nadrieril
92d65a92e2 Add tests 2024-05-04 16:20:47 +02:00
Ross Smyth
6967d1c0fc Stabilize exclusive_range 2024-05-02 19:42:31 -04:00
Gary Guo
cfee72aa24 Fix tests and bless 2024-04-24 13:12:33 +01:00
Nadrieril
50531806ee Add a non-shallow fake borrow 2024-04-20 16:01:35 +02:00
Nadrieril
511bd78863 Rework fake borrow calculation 2024-04-20 16:01:35 +02:00
Maybe Waffle
0bbe362901 Correctly change type when adding adjustments on top of NeverToAny 2024-04-19 11:05:02 +00:00
Maybe Waffle
4d749cad25 Add a test for a == b where a: !, b: ! 
(this currently produces malformed mir: we call `eq` with first argument not
being a reference)
 2024-04-19 11:05:02 +00:00
Oli Scherer
c8dfb59406 bless mir-opt tests 2024-04-08 15:08:06 +00:00