Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add basic Serde serialization capabilities to Stable MIR #126963

Merged
merged 1 commit into from
Jul 25, 2024

Conversation

sskeirik
Copy link
Contributor

@sskeirik sskeirik commented Jun 25, 2024

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:

  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.

@rustbot
Copy link
Collaborator

rustbot commented Jun 25, 2024

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 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
@rustbot
Copy link
Collaborator

rustbot commented Jun 25, 2024

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

@rust-log-analyzer

This comment has been minimized.

@oli-obk
Copy link
Contributor

oli-obk commented Jun 26, 2024

Please squash all commits, then this lgtm

@sskeirik
Copy link
Contributor Author

Squashed as requested and all tests showing passing results.

@oli-obk
Copy link
Contributor

oli-obk commented Jun 27, 2024

Thanks

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 27, 2024

📌 Commit 414ebea has been approved by oli-obk

It is now in the queue for this repository.

@bors 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 added a commit to GuillaumeGomez/rust that referenced this pull request Jun 27, 2024
…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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 27, 2024
…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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 27, 2024
…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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 27, 2024
…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
jhpratt added a commit to jhpratt/rust that referenced this pull request Jun 28, 2024
…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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 28, 2024
…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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2024
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2024
…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
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jun 28, 2024
…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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2024
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2024
…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
@bors 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
@oli-obk
Copy link
Contributor

oli-obk commented Jun 28, 2024

@bors r+ rollup=iffy

that failure looks like a miri failure

@bors
Copy link
Contributor

bors commented Jun 28, 2024

📌 Commit 414ebea has been approved by oli-obk

It is now in the queue for this repository.

@bors 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 a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2024
…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
Copy link
Contributor

bors commented Jun 28, 2024

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

@rust-log-analyzer
Copy link
Collaborator

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
Copy link
Contributor

bors commented Jun 28, 2024

💔 Test failed - checks-actions

@bors 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 a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2024
…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
Copy link
Contributor Author

sskeirik commented Jul 1, 2024

@oli-obk Thanks again for your review!

I have two questions about the status of this PR:

  1. In your view, did the CI failures that appeared previously when evaluating the roll-up seem to be due to this PR?
  2. 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
Copy link
Contributor

ehuss commented Jul 3, 2024

@bors r-

bors sync

@bors 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
@oli-obk
Copy link
Contributor

oli-obk commented Jul 3, 2024

  1. 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
Copy link
Contributor

celinval commented Jul 3, 2024

The failure seems specific to x86_64-msvc-ext.

@celinval
Copy link
Contributor

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
Copy link
Contributor

bors commented Jul 25, 2024

📌 Commit 414ebea has been approved by celinval

It is now in the queue for this repository.

@bors 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
Copy link
Contributor

bors commented Jul 25, 2024

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

@bors
Copy link
Contributor

bors commented Jul 25, 2024

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 25, 2024
@bors bors merged commit 7120fda into rust-lang:master Jul 25, 2024
7 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Jul 25, 2024
@rust-timer
Copy link
Collaborator

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
Copy link
Contributor Author

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants