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.

Sign up for GitHub

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

Jump to bottom

OpenVMM Rust 2024 Compatibility #288

Open
6 of 8 tasks
smalis-msft opened this issue Nov 11, 2024 · 2 comments
Open
6 of 8 tasks

OpenVMM Rust 2024 Compatibility #288

smalis-msft opened this issue Nov 11, 2024 · 2 comments
Assignees
@smalis-msft
Labels
linting Changes for better linting and/or their cleanups

Comments

@smalis-msft
Copy link
Contributor

smalis-msft commented Nov 11, 2024 •
edited
Loading

Tracking issue for known problems that will prevent OpenVMM from adopting the Rust 2024 edition once it is released. Ideally we will fully turn on the rust-2024-compatibility lint and remove all allows before making the switch.
@smalis-msft smalis-msft mentioned this issue Nov 11, 2024
Merged
@smalis-msft smalis-msft self-assigned this Nov 12, 2024
@smalis-msft smalis-msft added the linting Changes for better linting and/or their cleanups label Nov 12, 2024
smalis-msft added a commit that referenced this issue Nov 12, 2024
@smalis-msft
Begin working towards Rust 2024 compatibility (#289)
c5a665c 
This PR fixes up the easy issues with Rust 2024 compatibility and
enables the lint for it. However it also scopes out some allows for the
things that need some more work and focus. #288 is tracking them.

Changes in this PR:

- extern blocks are now unsafe
- `gen` is becoming a reserved keyword, rename variables
- mark unsafe attributes other than linkme's
- resolve the ambiguity of `fn poll` in VmbusSerialDriver
This was referenced Dec 17, 2024
Merged
Merged
smalis-msft added a commit that referenced this issue Dec 17, 2024
@smalis-msft
flowey: Avoid calling env::set_var (#513)
0dffce5 
Part of #288
smalis-msft added a commit that referenced this issue Dec 17, 2024
@smalis-msft
uh_init: Handle safety around set_var (#514)
b682370 
Part of #288
@smalis-msft smalis-msft mentioned this issue Dec 17, 2024
Merged
smalis-msft added a commit that referenced this issue Dec 18, 2024
@smalis-msft
uh_core: Don't modify the environment for start requests (#518)
8af001a 
Instead, just make our own environment clone. With additional
parameters! And annoying type conversions!

Part of #288
@smalis-msft smalis-msft mentioned this issue Dec 18, 2024
Merged
@smalis-msft smalis-msft mentioned this issue Dec 30, 2024
Merged
smalis-msft added a commit that referenced this issue Jan 2, 2025
@smalis-msft
Add safety comments to unsafe attributes (#592)
67e8f79 
Part of #288. This is not yet enforced by clippy
(rust-lang/rust-clippy#13316), but we should
be doing it anyways.
@smalis-msft smalis-msft mentioned this issue Jan 9, 2025
Merged
smalis-msft added a commit that referenced this issue Jan 14, 2025
@smalis-msft
Fixup return position impl trait overcapturing for the 2024 edition (#…
6375461 
…528)

The Rust 2024 edition will be changing how `impl Trait` in return
position functions. Namely it will be changing the rules from capturing
no lifetimes, to capturing all lifetimes. The reasons for this are
documented in [RFC
3498](https://github.com/rust-lang/rfcs/blob/master/text/3498-lifetime-capture-rules-2024.md)
and [the migration
guide](https://doc.rust-lang.org/nightly/edition-guide/rust-2024/rpit-lifetime-capture.html).
A new 'precise capturing' syntax has been added to allow cases that
don't need everything captured to scope down what they take. This PR
updates all such cases to use the new syntax.

Note that currently this new syntax requires all type parameters in
scope to be listed. This currently results in overcapturing of type
parameters. This will be relaxed in the future, and is tracked by [RFC
3617](rust-lang/rust#130043).

This PR also marks the edition_2024_expr_fragment_specifier lint as no
longer needing fixing, as I have completed an audit of all our macros
that it flagged and none of them need changing.

Part of #288
@smalis-msft smalis-msft mentioned this issue Jan 14, 2025
Merged
smalis-msft added a commit that referenced this issue Jan 14, 2025
@smalis-msft
Remove the global allow for deprecated_safe_2024, add an exclusion in…
f57a348 
… mesh (#668)

This will prevent any new uses of set/remove_env from coming into the
codebase. This one case in mesh requires nontrivial work to remove.
Tracked by #288.
benhillis pushed a commit to benhillis/openvmm that referenced this issue Jan 15, 2025
@smalis-msft
Begin working towards Rust 2024 compatibility (microsoft#289)
e3688c0 
This PR fixes up the easy issues with Rust 2024 compatibility and
enables the lint for it. However it also scopes out some allows for the
things that need some more work and focus. microsoft#288 is tracking them.

Changes in this PR:

- extern blocks are now unsafe
- `gen` is becoming a reserved keyword, rename variables
- mark unsafe attributes other than linkme's
- resolve the ambiguity of `fn poll` in VmbusSerialDriver
@smalis-msft
Copy link
Contributor Author

Some PRs are pending that will improve the behavior of the drop order lints in 1.87 (rust-lang/rust#137455, rust-lang/rust#137444). Given that we currently have over 1000 instances of those lints triggering I'm tempted to wait for these changes, unless we have a need to adopt the 2024 edition sooner.

@compiler-errors
Copy link

Yeah, I'd recommend to just wait a couple of days until that PR lands, and then try to migrate your crates with the latest nightly edition instead.

This was referenced Mar 10, 2025
Closed
Merged
smalis-msft added a commit that referenced this issue Mar 10, 2025
@smalis-msft
Misc 2024 edition compatibility fixes (#989)
5772618 
Some temporary lifetime changes and match restrictions. Found through
#988. Part of #288
This was referenced Mar 11, 2025
Merged
Merged
Closed
Merged
smalis-msft added a commit that referenced this issue Mar 11, 2025
@smalis-msft
Fix incorrect key name in rustfmt.toml (#1005)
6a362ae 
rustfmt.toml's 'edition' key only controls parsing behavior. We should
leave this to the default (read from Cargo.toml) so that rustfmt's
parsing behavior always matches what our code is targeting. Formatting
behavior is controlled by this separate key, 'style_edition', which we
can change separately from the actual code edition. This will allow us
to take 2024 edition formatting changes separately from code behavior
changes, should we so choose.

Part of #288
smalis-msft added a commit that referenced this issue Mar 11, 2025
@smalis-msft
Update our cargo-toml and toml-edit dependencies (#1006)
36a9319 
This brings Rust 2024 compatibility. Part of #288
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@smalis-msft smalis-msft

Labels
linting Changes for better linting and/or their cleanups
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@compiler-errors @smalis-msft