about summary refs log tree commit diff
path: root/tests/mir-opt/building/custom
AgeCommit message (Collapse)AuthorLines
2025-09-16Remove Rvalue::Len.Camille Gillot-4/+10
2025-08-04Dont print arg span in MIR dump for tail callMichael Goulet-1/+1
2025-01-18Revert "Auto merge of #134330 - scottmcm:no-more-rvalue-len, r=matthewjasper"Rémy Rakic-0/+36
This reverts commit e108481f74ff123ad98a63bd107a18d13035b275, reversing changes made to 303e8bd768526a5812bb1776e798e829ddb7d3ca.
2024-12-22Delete `Rvalue::Len`Scott McMurray-36/+0
Everything's moved to `PtrMetadata` instead.
2024-11-29Doc comment custom MIR debuginfo.Camille GILLOT-3/+38
and add a test for the constant case
2024-08-18Bless *all* the mir-opt testsScott McMurray-53/+53
2024-08-05custom MIR: add support for tail callsRalf Jung-0/+23
2024-06-07Revert "Create const block DefIds in typeck instead of ast lowering"Oli Scherer-1/+1
This reverts commit ddc5f9b6c1f21da5d4596bf7980185a00984ac42.
2024-06-03rustfmt `tests/mir-opt`.Nicholas Nethercote-1/+3
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-03Reformat `mir!` macro invocations to use braces.Nicholas Nethercote-169/+190
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-05-28Add custom mir support for `PtrMetadata`Scott McMurray-0/+23
2024-05-28Create const block DefIds in typeck instead of ast loweringOli Scherer-1/+1
2024-05-17Remove `Rvalue::CheckedBinaryOp`Scott McMurray-1/+1
2024-04-24Fix tests and blessGary Guo-3/+3
2024-03-23rename MIR int2ptr casts to match library nameRalf Jung-1/+1
2024-03-10MIR printing: print the path of uneval'd const; refer to promoteds in a ↵Ralf Jung-2/+2
consistent way
2024-02-22[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives许杰友 Jieyou Xu (Joe)-6/+6
2024-01-22Add Assume custom MIR.Camille GILLOT-0/+74
2023-12-26custom mir: make it clear what the return block isRalf Jung-8/+8
2023-11-14Custom MIR: Support cleanup blocksTomasz Miąsko-4/+106
Cleanup blocks are declared with `bb (cleanup) = { ... }`. `Call` and `Drop` terminators take an additional argument describing the unwind action, which is one of the following: * `UnwindContinue()` * `UnwindUnreachable()` * `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup` * `UnwindCleanup(block)` Also support unwind resume and unwind terminate terminators: * `UnwindResume()` * `UnwindTerminate(reason)`
2023-10-19Allow to run filecheck in mir-opt tests.Camille GILLOT-0/+13
2023-10-16Normalize alloc-id in tests.Camille GILLOT-4/+4
2023-09-01Support debuginfo for custom MIR.Camille GILLOT-0/+123
2023-08-19custom_mir: change Call() terminator syntax to something more readableRalf Jung-2/+2
2023-06-23Bless testsGary Guo-4/+4
2023-06-15Remove comments from mir-opt MIR dumpsBen Kimock-206/+194
2023-05-15Address FIXMEAndy Wang-11/+6
2023-05-15Add CopyForDeref to custom MIRAndy Wang-0/+28
2023-04-11Add Offset binary op to custom mirAndy Wang-0/+21
2023-03-22Rollup merge of #109392 - cbeuw:composite-ret, r=JakobDegenMatthias Krüger-0/+32
Custom MIR: Allow optional RET type annotation This currently doesn't compile because the type of `RET` is inferred, which fails if RET is a composite type and fields are initialised separately. ```rust #![feature(custom_mir, core_intrinsics)] extern crate core; use core::intrinsics::mir::*; #[custom_mir(dialect = "runtime", phase = "optimized")] fn fn0() -> (i32, bool) { mir! ({ RET.0 = 0; RET.1 = true; Return() }) } ``` ``` error[E0282]: type annotations needed --> src/lib.rs:8:9 | 8 | RET.0 = 0; | ^^^ cannot infer type For more information about this error, try `rustc --explain E0282`. ``` This PR allows the user to manually specify the return type with `type RET = ...;` if required: ```rust #[custom_mir(dialect = "runtime", phase = "optimized")] fn fn0() -> (i32, bool) { mir! ( type RET = (i32, bool); { RET.0 = 0; RET.1 = true; Return() } ) } ``` The syntax is not optimal, I'm happy to see other suggestions. Ideally I wanted it to be a normal type annotation like `let RET: ...;`, but this runs into the multiple parsing options error during macro expansion, as it can be parsed as a normal `let` declaration as well. r? ```@oli-obk``` or ```@tmiasko``` or ```@JakobDegen```
2023-03-20Support aggregate expressionsAndy Wang-0/+112
2023-03-20Allow optional RET type annotationAndy Wang-0/+32
2023-03-08Rollup merge of #108856 - Zeegomo:remove-drop-and-rep, r=tmiaskoMatthias Krüger-3/+5
Remove DropAndReplace terminator #107844 made DropAndReplace unused, let's remove it completely from the codebase.
2023-03-07Remove DropAndReplace terminatorGiacomo Pasini-3/+5
PR 107844 made DropAndReplace unused, let's remove it completely from the codebase.
2023-03-07Custom MIR: Support as castsAndy Wang-0/+73
2023-01-26Custom mir: Add support for some remaining, easy to support constructsJakob Degen-4/+46
2023-01-26Rollup merge of #107085 - tmiasko:custom-mir-operators, r=oli-obkMatthias Krüger-0/+54
Custom MIR: Support binary and unary operations Lower binary and unary operations directly to corresponding unchecked MIR operations. Ultimately this might not be syntax we want, but it allows for experimentation in the meantime. r? ````@oli-obk```` ````@JakobDegen````
2023-01-19Custom MIR: Support binary and unary operationsTomasz Miąsko-0/+54
2023-01-19Custom MIR: Support storage statementsTomasz Miąsko-5/+9
2023-01-12Fix mir-opt tests for big-endian platformsUlrich Weigand-4/+4
The test cases src/test/mir-opt/building/custom/consts.rs and src/test/mir-opt/const_prop/mutable_variable_no_prop.rs are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the MIR test files. Fix this by choosing constant values that have the same encoding on big- and little-endian platforms. The test case src/test/mir-opt/issues/issue_75439.rs is failing as well, but since the purpose of the test is to validate handling of big-endian integer encodings on a little-endian platform, it does not make much sense to run it on big-endian platforms in the first place - we can just ignore it there. Fixed part of https://github.com/rust-lang/rust/issues/105383.
2023-01-11Move /src/test to /testsAlbert Larsan-0/+823