Add basic Serde serialization capabilities to Stable MIR #126963

sskeirik · 2024-06-25T19:11:10Z

This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde derive), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted.

Notes

When I wrapped the Stable MIR error types in compiler/stable_mir/src/error.rs, it caused test failures (though I'm not sure why) so I backed those out.

Future Work

So, this PR will support serializing basic stable MIR, but it does not support serializing interned values beneath Tys and AllocIds, etc... My current thinking about how to handle this is as follows:

Add new visited_X fields to the Tables struct for each interned category of interest.
As serialization is occuring, serialize interned values as usual and also record the interned value we referenced in visited_X.

(Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well.
Teach the stable MIR Context how to access the visited_X values and expose them with wrappers in stable_mir/src/lib.rs to users (e.g. to serialize and/or further analyze them).

Pros

This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term.

Cons

The user will need to manually handle serializing interned values.

Alternatives

We can directly provide access to the underlying Tables maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need or users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above.
We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer and global values will possibly need to be de-duplicated on the consumer side.

rustbot · 2024-06-25T19:11:18Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

rustbot · 2024-06-25T19:11:20Z

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

oli-obk · 2024-06-26T06:31:22Z

Please squash all commits, then this lgtm

sskeirik · 2024-06-26T18:11:30Z

Squashed as requested and all tests showing passing results.

oli-obk · 2024-06-27T09:17:39Z

Thanks

@bors r+ rollup

bors · 2024-06-27T09:17:41Z

📌 Commit 414ebea has been approved by oli-obk

It is now in the queue for this repository.

…ive, r=oli-obk Add basic Serde serialization capabilities to Stable MIR This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde `derive`), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted. ## Notes When I wrapped the Stable MIR error types in `compiler/stable_mir/src/error.rs`, it caused test failures (though I'm not sure why) so I backed those out. ## Future Work So, this PR will support serializing basic stable MIR, but it _does not_ support serializing interned values beneath `Ty`s and `AllocId`s, etc... My current thinking about how to handle this is as follows: 1. Add new `visited_X` fields to the `Tables` struct for each interned category of interest. 2. As serialization is occuring, serialize interned values as usual _and_ also record the interned value we referenced in `visited_X`. (Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well. 3. Teach the stable MIR `Context` how to access the `visited_X` values and expose them with wrappers in `stable_mir/src/lib.rs` to users (e.g. to serialize and/or further analyze them). ### Pros This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term. ### Cons The user will need to manually handle serializing interned values. ### Alternatives 1. We can directly provide access to the underlying `Tables` maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need _or_ users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above. 2. We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer _and_ global values will possibly need to be de-duplicated on the consumer side.

…llaumeGomez Rollup of 10 pull requests Successful merges: - rust-lang#123237 (Various rustc_codegen_ssa cleanups) - rust-lang#123714 (Add test for fn pointer duplication.) - rust-lang#124091 (Update AST validation module docs) - rust-lang#126835 (Simplifications in match lowering) - rust-lang#126963 (Add basic Serde serialization capabilities to Stable MIR) - rust-lang#127010 (Update browser-ui-test version to `0.18.0`) - rust-lang#127015 (Switch back `non_local_definitions` lint to allow-by-default) - rust-lang#127016 (docs: check if the disambiguator matches its suffix) - rust-lang#127029 (Fix Markdown tables in platform-support.md) - rust-lang#127032 (Enable const casting for `f16` and `f128`) r? `@ghost` `@rustbot` modify labels: rollup

…ive, r=oli-obk Add basic Serde serialization capabilities to Stable MIR This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde `derive`), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted. ## Notes When I wrapped the Stable MIR error types in `compiler/stable_mir/src/error.rs`, it caused test failures (though I'm not sure why) so I backed those out. ## Future Work So, this PR will support serializing basic stable MIR, but it _does not_ support serializing interned values beneath `Ty`s and `AllocId`s, etc... My current thinking about how to handle this is as follows: 1. Add new `visited_X` fields to the `Tables` struct for each interned category of interest. 2. As serialization is occuring, serialize interned values as usual _and_ also record the interned value we referenced in `visited_X`. (Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well. 3. Teach the stable MIR `Context` how to access the `visited_X` values and expose them with wrappers in `stable_mir/src/lib.rs` to users (e.g. to serialize and/or further analyze them). ### Pros This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term. ### Cons The user will need to manually handle serializing interned values. ### Alternatives 1. We can directly provide access to the underlying `Tables` maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need _or_ users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above. 2. We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer _and_ global values will possibly need to be de-duplicated on the consumer side.

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#123237 (Various rustc_codegen_ssa cleanups) - rust-lang#123714 (Add test for fn pointer duplication.) - rust-lang#124091 (Update AST validation module docs) - rust-lang#126835 (Simplifications in match lowering) - rust-lang#126963 (Add basic Serde serialization capabilities to Stable MIR) - rust-lang#127010 (Update browser-ui-test version to `0.18.0`) - rust-lang#127015 (Switch back `non_local_definitions` lint to allow-by-default) - rust-lang#127029 (Fix Markdown tables in platform-support.md) - rust-lang#127032 (Enable const casting for `f16` and `f128`) r? `@ghost` `@rustbot` modify labels: rollup

…ive, r=oli-obk Add basic Serde serialization capabilities to Stable MIR This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde `derive`), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted. ## Notes When I wrapped the Stable MIR error types in `compiler/stable_mir/src/error.rs`, it caused test failures (though I'm not sure why) so I backed those out. ## Future Work So, this PR will support serializing basic stable MIR, but it _does not_ support serializing interned values beneath `Ty`s and `AllocId`s, etc... My current thinking about how to handle this is as follows: 1. Add new `visited_X` fields to the `Tables` struct for each interned category of interest. 2. As serialization is occuring, serialize interned values as usual _and_ also record the interned value we referenced in `visited_X`. (Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well. 3. Teach the stable MIR `Context` how to access the `visited_X` values and expose them with wrappers in `stable_mir/src/lib.rs` to users (e.g. to serialize and/or further analyze them). ### Pros This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term. ### Cons The user will need to manually handle serializing interned values. ### Alternatives 1. We can directly provide access to the underlying `Tables` maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need _or_ users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above. 2. We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer _and_ global values will possibly need to be de-duplicated on the consumer side.

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#123237 (Various rustc_codegen_ssa cleanups) - rust-lang#123714 (Add test for fn pointer duplication.) - rust-lang#124091 (Update AST validation module docs) - rust-lang#126835 (Simplifications in match lowering) - rust-lang#126963 (Add basic Serde serialization capabilities to Stable MIR) - rust-lang#127015 (Switch back `non_local_definitions` lint to allow-by-default) - rust-lang#127029 (Fix Markdown tables in platform-support.md) - rust-lang#127032 (Enable const casting for `f16` and `f128`) r? `@ghost` `@rustbot` modify labels: rollup

…ive, r=oli-obk Add basic Serde serialization capabilities to Stable MIR This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde `derive`), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted. ## Notes When I wrapped the Stable MIR error types in `compiler/stable_mir/src/error.rs`, it caused test failures (though I'm not sure why) so I backed those out. ## Future Work So, this PR will support serializing basic stable MIR, but it _does not_ support serializing interned values beneath `Ty`s and `AllocId`s, etc... My current thinking about how to handle this is as follows: 1. Add new `visited_X` fields to the `Tables` struct for each interned category of interest. 2. As serialization is occuring, serialize interned values as usual _and_ also record the interned value we referenced in `visited_X`. (Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well. 3. Teach the stable MIR `Context` how to access the `visited_X` values and expose them with wrappers in `stable_mir/src/lib.rs` to users (e.g. to serialize and/or further analyze them). ### Pros This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term. ### Cons The user will need to manually handle serializing interned values. ### Alternatives 1. We can directly provide access to the underlying `Tables` maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need _or_ users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above. 2. We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer _and_ global values will possibly need to be de-duplicated on the consumer side.

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#123237 (Various rustc_codegen_ssa cleanups) - rust-lang#123714 (Add test for fn pointer duplication.) - rust-lang#124091 (Update AST validation module docs) - rust-lang#126835 (Simplifications in match lowering) - rust-lang#126963 (Add basic Serde serialization capabilities to Stable MIR) - rust-lang#127015 (Switch back `non_local_definitions` lint to allow-by-default) - rust-lang#127029 (Fix Markdown tables in platform-support.md) - rust-lang#127032 (Enable const casting for `f16` and `f128`) r? `@ghost` `@rustbot` modify labels: rollup

…llaumeGomez Rollup of 10 pull requests Successful merges: - rust-lang#123714 (Add test for fn pointer duplication.) - rust-lang#124091 (Update AST validation module docs) - rust-lang#126963 (Add basic Serde serialization capabilities to Stable MIR) - rust-lang#127015 (Switch back `non_local_definitions` lint to allow-by-default) - rust-lang#127016 (docs: check if the disambiguator matches its suffix) - rust-lang#127029 (Fix Markdown tables in platform-support.md) - rust-lang#127032 (Enable const casting for `f16` and `f128`) - rust-lang#127041 (Migrate `run-make/override-aliased-flags` to `rmake.rs`) - rust-lang#127045 (Rename `super_predicates_of` and similar queries to `explicit_*` to note that they're not elaborated) - rust-lang#127075 (rustc_data_structures: Explicitly check for 64-bit atomics support) r? `@ghost` `@rustbot` modify labels: rollup

oli-obk · 2024-06-28T13:42:02Z

@bors r+ rollup=iffy

that failure looks like a miri failure

bors · 2024-06-28T13:42:05Z

📌 Commit 414ebea has been approved by oli-obk

It is now in the queue for this repository.

…e, r=oli-obk Add basic Serde serialization capabilities to Stable MIR This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde `derive`), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted. ## Notes When I wrapped the Stable MIR error types in `compiler/stable_mir/src/error.rs`, it caused test failures (though I'm not sure why) so I backed those out. ## Future Work So, this PR will support serializing basic stable MIR, but it _does not_ support serializing interned values beneath `Ty`s and `AllocId`s, etc... My current thinking about how to handle this is as follows: 1. Add new `visited_X` fields to the `Tables` struct for each interned category of interest. 2. As serialization is occuring, serialize interned values as usual _and_ also record the interned value we referenced in `visited_X`. (Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well. 3. Teach the stable MIR `Context` how to access the `visited_X` values and expose them with wrappers in `stable_mir/src/lib.rs` to users (e.g. to serialize and/or further analyze them). ### Pros This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term. ### Cons The user will need to manually handle serializing interned values. ### Alternatives 1. We can directly provide access to the underlying `Tables` maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need _or_ users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above. 2. We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer _and_ global values will possibly need to be de-duplicated on the consumer side.

bors · 2024-06-28T14:28:17Z

⌛ Testing commit 414ebea with merge 5233f51...

rust-log-analyzer · 2024-06-28T16:04:07Z

The job x86_64-msvc-ext failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    
    ---- abi.md - Application_Binary_Interface__ABI_::The_ (line 20) stdout ----
    error: linking with `link.exe` failed: exit code: 1120
      |
      = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.40.33807\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "C:\\a\\_temp\\msys64\\tmp\\rustco7pfDh\\symbols.o" "C:\\a\\_temp\\msys64\\tmp\\rustdoctestv1LZxt\\rust_out.rust_out.e3abed174610e5f2-cgu.0.rcgu.o" "C:\\a\\_temp\\msys64\\tmp\\rustdoctestv1LZxt\\rust_out.3q0trpzx01svb1e59zzs0qep7.rcgu.o" "/LIBPATH:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-206083cb6bc4d475.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-99645fe50ce44166.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_demangle-61b4562231042fd0.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_detect-81cfc1256b6fbf6e.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libhashbrown-32b5e8b3646f8f41.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_alloc-eff6e1d33fba116e.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-90643aa787b02322.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcfg_if-c83f178b1eb06b75.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-49b3a906698dafaf.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_core-ced70f8369d90b15.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-e4d31ad4edfac595.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-b05085058f881bfe.rlib" "kernel32.lib" "advapi32.lib" "kernel32.lib" "ntdll.lib" "userenv.lib" "ws2_32.lib" "kernel32.lib" "ws2_32.lib" "kernel32.lib" "/defaultlib:msvcrt" "/NXCOMPAT" "/LIBPATH:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "/OUT:C:\\a\\_temp\\msys64\\tmp\\rustdoctestv1LZxt\\rust_out.exe" "/OPT:REF,NOICF" "/DEBUG" "/PDBALTPATH:%_PDB%"
      = note: symbols.o : error LNK2001: unresolved external symbol _ZN8rust_out4main25_doctest_main_abi_md_20_03FOO17h3aef1f97c85f704cE
              C:\a\_temp\msys64\tmp\rustdoctestv1LZxt\rust_out.exe : fatal error LNK1120: 1 unresolved externals
    
    error: aborting due to 1 previous error
    
    Couldn't compile the test.
---
[RUSTC-TIMING] miri test:false 61.806
[RUSTC-TIMING] miri test:false 3.201
    Finished `release` profile [optimized] target(s) in 0.38s
thread 'main' panicked at src/lib.rs:1712:17:
failed to copy `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-tools\x86_64-pc-windows-msvc\release\miri.exe` to `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-tools-bin\miri.exe`: The process cannot access the file because it is being used by another process. (os error 32)
##[endgroup]
Build completed unsuccessfully in 0:00:14
  local time: Fri, Jun 28, 2024  4:03:54 PM
  network time: Fri, 28 Jun 2024 16:03:55 GMT

bors · 2024-06-28T16:05:00Z

💔 Test failed - checks-actions

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#123237 (Various rustc_codegen_ssa cleanups) - rust-lang#123714 (Add test for fn pointer duplication.) - rust-lang#124091 (Update AST validation module docs) - rust-lang#126835 (Simplifications in match lowering) - rust-lang#126963 (Add basic Serde serialization capabilities to Stable MIR) - rust-lang#127015 (Switch back `non_local_definitions` lint to allow-by-default) - rust-lang#127029 (Fix Markdown tables in platform-support.md) - rust-lang#127032 (Enable const casting for `f16` and `f128`) r? `@ghost` `@rustbot` modify labels: rollup

sskeirik · 2024-07-01T23:30:50Z

@oli-obk Thanks again for your review!

I have two questions about the status of this PR:

In your view, did the CI failures that appeared previously when evaluating the roll-up seem to be due to this PR?
If no to (1), is it possible to try again to see if that resolves the issue? I am happy to rebase this to a later rustc version (or make any other adjustments) if that would be helpful.

Thanks much!

CI Failure Log Notes

From reading the CI failure log, it looks like the miri build failed due to a file copy error (build failure copied below for your convenience).

As far as I can tell, this is either a sporadic CI issue or related to a different PR in the roll-up.

I'd love to know your thoughts!

2024-06-28T16:03:54.3104645Z ##[group]Building tool miri (stage1 -> stage2, x86_64-pc-windows-msvc)
2024-06-28T16:03:54.6987912Z [RUSTC-TIMING] build_script_build test:false 0.501
2024-06-28T16:03:54.6989562Z [RUSTC-TIMING] cfg_if test:false 0.070
2024-06-28T16:03:54.6990683Z [RUSTC-TIMING] autocfg test:false 1.079
2024-06-28T16:03:54.6992296Z [RUSTC-TIMING] ppv_lite86 test:false 1.100
2024-06-28T16:03:54.6993499Z [RUSTC-TIMING] siphasher test:false 0.478
2024-06-28T16:03:54.6995065Z [RUSTC-TIMING] cfg_if test:false 0.055
2024-06-28T16:03:54.6996620Z [RUSTC-TIMING] version_check test:false 0.930
2024-06-28T16:03:54.6997883Z [RUSTC-TIMING] regex_syntax test:false 9.921
2024-06-28T16:03:54.6999293Z [RUSTC-TIMING] getrandom test:false 0.328
2024-06-28T16:03:54.7000576Z [RUSTC-TIMING] memchr test:false 1.566
2024-06-28T16:03:54.7001866Z [RUSTC-TIMING] phf_shared test:false 0.414
2024-06-28T16:03:54.7003165Z [RUSTC-TIMING] build_script_main test:false 1.340
2024-06-28T16:03:54.7005134Z [RUSTC-TIMING] build_script_build test:false 0.351
2024-06-28T16:03:54.7007025Z [RUSTC-TIMING] windows_targets test:false 0.055
2024-06-28T16:03:54.7008317Z [RUSTC-TIMING] build_script_build test:false 0.320
2024-06-28T16:03:54.7010325Z [RUSTC-TIMING] build_script_build test:false 0.343
2024-06-28T16:03:54.7012294Z [RUSTC-TIMING] rand_core test:false 0.459
2024-06-28T16:03:54.7013545Z [RUSTC-TIMING] aho_corasick test:false 6.907
2024-06-28T16:03:54.7015027Z [RUSTC-TIMING] phf test:false 0.306
2024-06-28T16:03:54.7016361Z [RUSTC-TIMING] build_script_build test:false 0.487
2024-06-28T16:03:54.7018548Z [RUSTC-TIMING] rand_chacha test:false 1.279
2024-06-28T16:03:54.7019796Z [RUSTC-TIMING] regex_automata test:false 6.292
2024-06-28T16:03:54.7021026Z [RUSTC-TIMING] typenum test:false 1.819
2024-06-28T16:03:54.7022359Z [RUSTC-TIMING] getrandom test:false 0.397
2024-06-28T16:03:54.7023695Z [RUSTC-TIMING] smallvec test:false 0.616
2024-06-28T16:03:54.7024941Z [RUSTC-TIMING] scopeguard test:false 0.100
2024-06-28T16:03:54.7026254Z [RUSTC-TIMING] windows_targets test:false 0.054
2024-06-28T16:03:54.7027549Z [RUSTC-TIMING] rand test:false 2.140
2024-06-28T16:03:54.7028760Z [RUSTC-TIMING] regex test:false 1.091
2024-06-28T16:03:54.7030106Z [RUSTC-TIMING] generic_array test:false 2.099
2024-06-28T16:03:54.7031309Z [RUSTC-TIMING] siphasher test:false 0.549
2024-06-28T16:03:54.7032535Z [RUSTC-TIMING] rand_core test:false 0.703
2024-06-28T16:03:54.7033767Z [RUSTC-TIMING] windows_sys test:false 8.030
2024-06-28T16:03:54.7035053Z [RUSTC-TIMING] lock_api test:false 0.608
2024-06-28T16:03:54.7036382Z [RUSTC-TIMING] parking_lot_core test:false 1.199
2024-06-28T16:03:54.7037808Z [RUSTC-TIMING] phf_generator test:false 0.161
2024-06-28T16:03:54.7039516Z [RUSTC-TIMING] parse_zoneinfo test:false 0.871
2024-06-28T16:03:54.7040940Z [RUSTC-TIMING] crypto_common test:false 0.167
2024-06-28T16:03:54.7042162Z [RUSTC-TIMING] phf_shared test:false 0.589
2024-06-28T16:03:54.7043354Z [RUSTC-TIMING] inout test:false 0.229
2024-06-28T16:03:54.7044716Z [RUSTC-TIMING] num_traits test:false 2.793
2024-06-28T16:03:54.7046014Z [RUSTC-TIMING] ppv_lite86 test:false 1.038
2024-06-28T16:03:54.7047176Z [RUSTC-TIMING] option_ext test:false 0.085
2024-06-28T16:03:54.7048536Z [RUSTC-TIMING] phf_codegen test:false 0.206
2024-06-28T16:03:54.7049731Z [RUSTC-TIMING] cipher test:false 0.613
2024-06-28T16:03:54.7050932Z [RUSTC-TIMING] phf test:false 0.366
2024-06-28T16:03:54.7052134Z [RUSTC-TIMING] chrono test:false 5.245
2024-06-28T16:03:54.7053366Z [RUSTC-TIMING] dirs_sys test:false 0.243
2024-06-28T16:03:54.7054598Z [RUSTC-TIMING] rand_chacha test:false 2.658
2024-06-28T16:03:54.7055848Z [RUSTC-TIMING] parking_lot test:false 3.547
2024-06-28T16:03:54.7057109Z [RUSTC-TIMING] windows_sys test:false 7.753
2024-06-28T16:03:54.7058485Z [RUSTC-TIMING] chrono_tz_build test:false 0.628
2024-06-28T16:03:54.7059696Z [RUSTC-TIMING] log test:false 0.646
2024-06-28T16:03:54.7060938Z [RUSTC-TIMING] cpufeatures test:false 0.068
2024-06-28T16:03:54.7062204Z [RUSTC-TIMING] rustc_hash test:false 0.130
2024-06-28T16:03:54.7063550Z [RUSTC-TIMING] build_script_build test:false 0.417
2024-06-28T16:03:54.7065453Z [RUSTC-TIMING] rand test:false 3.088
2024-06-28T16:03:54.7066758Z [RUSTC-TIMING] directories test:false 0.583
2024-06-28T16:03:54.7067963Z [RUSTC-TIMING] ctrlc test:false 0.197
2024-06-28T16:03:54.7069367Z [RUSTC-TIMING] build_script_build test:false 0.274
2024-06-28T16:03:54.7071336Z [RUSTC-TIMING] aes test:false 3.843
2024-06-28T16:03:54.7072718Z [RUSTC-TIMING] measureme test:false 2.759
2024-06-28T16:03:54.7074182Z [RUSTC-TIMING] chrono_tz test:false 5.853
2024-06-28T16:03:54.7075460Z [RUSTC-TIMING] miri test:false 61.806
2024-06-28T16:03:54.7077431Z [RUSTC-TIMING] miri test:false 3.201
2024-06-28T16:03:54.7079854Z �[1m�[32m    Finished�[0m `release` profile [optimized] target(s) in 0.38s
2024-06-28T16:03:54.7298453Z thread 'main' panicked at src/lib.rs:1712:17:
2024-06-28T16:03:54.7300791Z failed to copy `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-tools\x86_64-pc-windows-msvc\release\miri.exe` to `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-tools-bin\miri.exe`: The process cannot access the file because it is being used by another process. (os error 32)
2024-06-28T16:03:54.7303033Z note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2024-06-28T16:03:54.7361827Z ##[endgroup]
2024-06-28T16:03:54.7404982Z Build completed unsuccessfully in 0:00:14
2024-06-28T16:03:54.7710109Z   local time: Fri, Jun 28, 2024  4:03:54 PM
2024-06-28T16:03:55.0236728Z   network time: Fri, 28 Jun 2024 16:03:55 GMT
2024-06-28T16:03:55.0290448Z ##[error]Process completed with exit code 1.

ehuss · 2024-07-03T00:30:22Z

@bors r-

bors sync

oli-obk · 2024-07-03T09:34:05Z

In your view, did the CI failures that appeared previously when evaluating the roll-up seem to be due to this PR?

it seems likely considering they occurred twice, but I don't really know how that can happen. Try running miri tests locally to see if it reproduces

celinval · 2024-07-03T17:01:02Z

The failure seems specific to x86_64-msvc-ext.

celinval · 2024-07-25T17:49:19Z

I really don't see how this PR could be breaking CI. I also noticed that different runs presented similar errors (failed to copy an artifact because it is currently being used), however, with different artifacts.

Also, this PR (#127096) was created without this change, and it had similar failure: #127096 (comment). A retry seemed to have fixed the issue.

@bors r+

bors · 2024-07-25T17:49:22Z

📌 Commit 414ebea has been approved by celinval

It is now in the queue for this repository.

bors · 2024-07-25T20:27:56Z

⌛ Testing commit 414ebea with merge 7120fda...

bors · 2024-07-25T22:49:46Z

☀️ Test successful - checks-actions
Approved by: celinval
Pushing 7120fda to master...

rust-timer · 2024-07-26T01:25:15Z

Finished benchmarking commit (7120fda): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (secondary 7.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	7.1%	[7.1%, 7.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 771.494s -> 770.291s (-0.16%)
Artifact size: 328.93 MiB -> 328.92 MiB (-0.00%)

sskeirik · 2024-07-26T19:21:24Z

@celinval Thanks for re-running this! Glad to get this merged so we can have an easy-to-consume representation of the stable MIR AST!

rustbot assigned oli-obk Jun 25, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 25, 2024

This comment has been minimized.

Sign in to view

add serde derive Serialize to stable_mir

414ebea

sskeirik force-pushed the smir_serde_derive branch from 8184e2d to 414ebea Compare June 26, 2024 15:56

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 27, 2024

GuillaumeGomez mentioned this pull request Jun 27, 2024

Rollup of 10 pull requests #127046

Closed

matthiaskrgr mentioned this pull request Jun 27, 2024

Rollup of 9 pull requests #127056

Closed

jhpratt mentioned this pull request Jun 28, 2024

Rollup of 12 pull requests #127064

Closed

matthiaskrgr mentioned this pull request Jun 28, 2024

Rollup of 8 pull requests #127066

Closed

GuillaumeGomez mentioned this pull request Jun 28, 2024

Rollup of 10 pull requests #127079

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 28, 2024

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 28, 2024

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 28, 2024

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 3, 2024

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 25, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 25, 2024

bors merged commit 7120fda into rust-lang:master Jul 25, 2024
7 checks passed

rustbot added this to the 1.82.0 milestone Jul 25, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add basic Serde serialization capabilities to Stable MIR #126963

Add basic Serde serialization capabilities to Stable MIR #126963

sskeirik commented Jun 25, 2024 •

edited

Loading

rustbot commented Jun 25, 2024

rustbot commented Jun 25, 2024

This comment has been minimized.

oli-obk commented Jun 26, 2024

sskeirik commented Jun 26, 2024

oli-obk commented Jun 27, 2024

bors commented Jun 27, 2024

oli-obk commented Jun 28, 2024

bors commented Jun 28, 2024

bors commented Jun 28, 2024

rust-log-analyzer commented Jun 28, 2024

bors commented Jun 28, 2024

sskeirik commented Jul 1, 2024

ehuss commented Jul 3, 2024

oli-obk commented Jul 3, 2024

celinval commented Jul 3, 2024

celinval commented Jul 25, 2024

bors commented Jul 25, 2024

bors commented Jul 25, 2024

bors commented Jul 25, 2024

rust-timer commented Jul 26, 2024

sskeirik commented Jul 26, 2024

Add basic Serde serialization capabilities to Stable MIR #126963

Add basic Serde serialization capabilities to Stable MIR #126963

Conversation

sskeirik commented Jun 25, 2024 • edited Loading

Notes

Future Work

Pros

Cons

Alternatives

rustbot commented Jun 25, 2024

rustbot commented Jun 25, 2024

This comment has been minimized.

oli-obk commented Jun 26, 2024

sskeirik commented Jun 26, 2024

oli-obk commented Jun 27, 2024

bors commented Jun 27, 2024

oli-obk commented Jun 28, 2024

bors commented Jun 28, 2024

bors commented Jun 28, 2024

rust-log-analyzer commented Jun 28, 2024

bors commented Jun 28, 2024

sskeirik commented Jul 1, 2024

CI Failure Log Notes

ehuss commented Jul 3, 2024

oli-obk commented Jul 3, 2024

celinval commented Jul 3, 2024

celinval commented Jul 25, 2024

bors commented Jul 25, 2024

bors commented Jul 25, 2024

bors commented Jul 25, 2024

rust-timer commented Jul 26, 2024

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

sskeirik commented Jul 26, 2024

sskeirik commented Jun 25, 2024 •

edited

Loading