No description
Find a file
bors 8eba6960d5 Auto merge of #126963 - runtimeverification:smir_serde_derive, r=celinval
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.
2024-07-25 20:27:51 +00:00
.cargo fix: Fix generated markers not being patchable in package.json 2024-06-08 12:54:43 +02:00
.github Bump actions/download-artifact and upload-artifact 2024-06-25 20:32:09 +03:00
.vscode Spelling 2023-04-19 09:45:55 -04:00
assets Automatically change text color in logo based on dark mode 2022-03-06 23:06:53 +11:00
bench_data Spelling 2023-04-19 09:45:55 -04:00
crates Allow deprecated temporarily to unblock version bump 2024-07-20 15:51:58 -04:00
docs feat: add inlay hints for generic parameters 2024-07-08 19:11:41 +08:00
editors/code Remove faq landing page, improve main one 2024-07-10 19:05:32 +02:00
lib style: simplify string interpolation 2024-05-30 16:18:49 -07:00
xtask Inline all the things 2024-07-07 11:18:40 +02:00
.editorconfig add max_line_length to .editorconfig 2024-01-20 17:14:00 +03:00
.git-blame-ignore-revs Show workspace info in the status bar 2024-04-26 11:28:33 +02:00
.gitattributes Fix .gitattributes for test_data 2022-07-24 14:05:35 +02:00
.gitignore internal: add "Shuffle Crate Graph" command 2021-12-07 16:37:19 +01:00
.typos.toml remove ignore-hidden = false 2024-03-05 20:16:32 +08:00
Cargo.lock Add f16 and f128 support 2024-07-10 10:43:14 +01:00
Cargo.toml Add f16 and f128 support 2024-07-10 10:43:14 +01:00
clippy.toml Lint debug prints and disallowed types with clippy 2024-02-01 17:57:27 +01:00
CONTRIBUTING.md Add CONTRIBUTING.md 2024-04-18 10:24:40 +02:00
LICENSE-APACHE Licenses 2018-01-10 22:47:04 +03:00
LICENSE-MIT Licenses 2018-01-10 22:47:04 +03:00
PRIVACY.md Update privacy note 2021-12-23 14:04:15 +02:00
README.md Add CONTRIBUTING.md 2024-04-18 10:24:40 +02:00
rust-bors.toml Prepare for rust-bors 2023-10-05 15:26:09 +03:00
rust-version Preparing for merge from rust-lang/rust 2024-07-11 20:05:52 +03:00
rustfmt.toml Shuffle hir-expand things around 2024-01-26 19:28:39 +01:00
triagebot.toml Update triagebot.toml 2024-06-27 10:32:13 +02:00

rust-analyzer logo

rust-analyzer is a modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust.

Quick Start

https://rust-analyzer.github.io/manual.html#installation

Documentation

If you want to contribute to rust-analyzer check out the CONTRIBUTING.md or if you are just curious about how things work under the hood, check the ./docs/dev folder.

If you want to use rust-analyzer's language server with your editor of choice, check the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.

Security and Privacy

See the corresponding sections of the manual.

Communication

For usage and troubleshooting requests, please use "IDEs and Editors" category of the Rust forum:

https://users.rust-lang.org/c/ide/14

For questions about development and implementation, join rust-analyzer working group on Zulip:

https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer

License

rust-analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).

See LICENSE-APACHE and LICENSE-MIT for details.