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 · 0 comments
Open
6 of 8 tasks

OpenVMM Rust 2024 Compatibility #288

smalis-msft opened this issue Nov 11, 2024 · 0 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
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
1 participant
@smalis-msft