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

Nightly incompatibility #15

Closed
ProphetLamb opened this issue Mar 1, 2023 · 9 comments
Closed

Nightly incompatibility #15

ProphetLamb opened this issue Mar 1, 2023 · 9 comments

Comments

@ProphetLamb
Copy link

This project does not build against nightly-x86_64-pc-windows-msvc and nightly-i686-pc-windows-msv.
Building against the stable-x86_64-pc-windows-msv raises a future incompatibility warning.

Here is the full report produced by cargo report future-incompatibilities --id 23 --package ntapi@0.3.7:

The following warnings were discovered during the build. These warnings are an
indication that the packages contain code that will become an error in a
future release of Rust. These warnings typically cover changes to close
soundness problems, unintended or undocumented behavior, or critical problems
that cannot be fixed in a backwards-compatible fashion, and are not expected
to be in wide use.

Each warning should contain a link for more information on what the warning
means and how to resolve it.


To solve this problem, you can try the following approaches:


- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the issue has been fixed.

ntapi v0.3.7 has the following newer versions available: 0.4.0


- If the issue is not solved by updating the dependencies, a fix has to be
implemented by those dependencies. You can help with that by notifying the
maintainers of this problem (e.g. by creating a bug report) or by proposing a
fix to the maintainers (e.g. by creating a pull request):

  - ntapi@0.3.7
  - Repository: https://github.com/MSxDOS/ntapi
  - Detailed warning command: `cargo report future-incompatibilities --id 23 --package ntapi@0.3.7`

- If waiting for an upstream fix is not an option, you can use the `[patch]`
section in `Cargo.toml` to use your own version of the dependency. For more
information, see:
https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section

The package `ntapi v0.3.7` currently triggers the following future incompatibility lints:
> warning: reference to packed field is unaligned
>     --> ~\.cargo\registry\src\github.com-1ecc6299db9ec823\ntapi-0.3.7\src\ntexapi.rs:2783:52
>      |
> 2783 |         *tick_count.QuadPart_mut() = read_volatile(&(*USER_SHARED_DATA).u.TickCountQuad);
>      |                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      |
>      = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>      = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
>      = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
>      = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
>      = note: `#[allow(unaligned_references)]` on by default
>
> warning: reference to packed field is unaligned
>     --> ~\.cargo\registry\src\github.com-1ecc6299db9ec823\ntapi-0.3.7\src\ntexapi.rs:2807:25
>      |
> 2807 |         ((read_volatile(&(*USER_SHARED_DATA).u.TickCountQuad)
>      |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      |
>      = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>      = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
>      = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
>      = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)
>      = note: `#[allow(unaligned_references)]` on by default
>
@TheBlueMatt
Copy link

This is now failing on beta, so I guess will be an issue on stable rust soon :(.

@nnethercote
Copy link

We are hitting this in rust-lang/rustc-perf#1536.

@RalfJung
Copy link

According to ClementTsang/bottom#1056, this is fixed in ntapi 0.4.0, so an update should help (but might need to be pushed through multiple layers of crates).

@nnethercote
Copy link

We are hitting this in rust-lang/rustc-perf#1536.

We fixed this in rust-lang/rustc-perf#1540 by updating tokio from 1.6 to 1.26. This updated the mio version from 0.7.11 to 0.8.6, which removed the ntapi dependency.

@TheBlueMatt
Copy link

Sadly newer tokio also has a substantially higher MSRV, and waiting for things to move to ntapi 0.4 is not something that's going to happen quickly. It would be nice if a patch version were uploaded with the fix.

@Darksonn
Copy link

With the release of rust 1.69, this is causing Tokio's CI to fail because ntapi is still used in tests. I'm sure it's also causing lots of other failures.

It might make sense to rename this issue now that it has reached stable.

@MSxDOS
Copy link
Owner

MSxDOS commented Apr 20, 2023

Issues related to unaligned references should be fixed in 0.4.1

@MSxDOS MSxDOS closed this as completed Apr 20, 2023
@TheBlueMatt
Copy link

Is there any chance there will be an ntapi 0.3.8? Sadly the last version of tokio which works on a broad set of available rustc's depends on ntapi 0.3, which won't get the fixes in ntapi 0.4.1.

@ryoqun
Copy link

ryoqun commented May 11, 2023

@MSxDOS hey, sorry for re-posting similar comments here as well. however as said previously (ref: #12 (comment)), we're stuck at deps as well via tokio. and it seems we're not the only one who are affected.

could you reconsider to publish a teeny patch for 0.3.x? I hope that won't take your time not much... Thanks in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants