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

GuillaumeGomez · 2024-06-28T12:36:28Z

I think this is the PR which failed in #127079 (comment). I r- t but don't hesitate to re-approve it if I'm wrong.

@bors r-

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

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

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

GuillaumeGomez commented Jun 28, 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

Add basic Serde serialization capabilities to Stable MIR #126963

Are you sure you want to change the base?

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

GuillaumeGomez commented Jun 28, 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 Jun 25, 2024 •

edited

Loading