Bump patched ntapi from v0.3.6 to v0.3.7

[ryoqun]

Problem

the solana git repo and published spl crate are using different versions of ntapi, which is troubling consistent [patch]-ing. the repo had been pinning to v0.3.6 via Cargo.lock. but the published spl crate is specifying v0.3.x and resolved to latest one: v0.3.7

Summary of Changes

Just use same version, restoring --locked.

so, this effectively bumps monorepo's ntapi from v0.3.6 to v0.3.7, which seems to contain only small changes:

MSxDOS/ntapi@cbea31e...3a0063a according to:

$ git diff --no-index ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.{6,7}/.cargo_vcs_info.json
diff --git a/home/ryoqun/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.6/.cargo_vcs_info.json b/home/ryoqun/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.7/.cargo_vcs_info.json
index 8ae34a3dff4..d974c8a1461 100644
--- a/home/ryoqun/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.6/.cargo_vcs_info.json
+++ b/home/ryoqun/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.7/.cargo_vcs_info.json
@@ -1,5 +1,6 @@
 {
   "git": {
-    "sha1": "cbea31ea9d624169f01ae0997e6698baceb51867"
-  }
-}
+    "sha1": "3a0063ad916e5f0c6972ab53e025689b9f0f92ad"
+  },
+  "path_in_vcs": ""
+}
\ No newline at end of file

new patch commit: solana-labs/ntapi@97ede98 :

$ git diff --no-index ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.7/src/ ./src/
diff --git a/home/ryoqun/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.7/src/ntexapi.rs b/./src/ntexapi.rs
index 5fa47c9..d48749d 100644
--- a/home/ryoqun/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ntapi-0.3.7/src/ntexapi.rs
+++ b/./src/ntexapi.rs
@@ -1,4 +1,6 @@
 use core::mem::uninitialized;
+#[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))]
+use core::ptr::addr_of;
 use core::ptr::read_volatile;
 #[cfg(target_arch = "x86")]
 use core::sync::atomic::spin_loop_hint;
@@ -2780,7 +2782,7 @@ pub const USER_SHARED_DATA: *const KUSER_SHARED_DATA = 0x7ffe0000 as *const _;
 pub unsafe fn NtGetTickCount64() -> ULONGLONG {
     let mut tick_count: ULARGE_INTEGER = uninitialized();
     #[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))] {
-        *tick_count.QuadPart_mut() = read_volatile(&(*USER_SHARED_DATA).u.TickCountQuad);
+        *tick_count.QuadPart_mut() = read_volatile(addr_of!((*USER_SHARED_DATA).u.TickCountQuad));
     }
     #[cfg(target_arch = "x86")] {
         loop {
@@ -2804,7 +2806,7 @@ pub unsafe fn NtGetTickCount64() -> ULONGLONG {
 #[inline]
 pub unsafe fn NtGetTickCount() -> ULONG {
     #[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))] {
-        ((read_volatile(&(*USER_SHARED_DATA).u.TickCountQuad)
+        ((read_volatile(addr_of!((*USER_SHARED_DATA).u.TickCountQuad))
             * (*USER_SHARED_DATA).TickCountMultiplier as u64) >> 24) as u32
     }
     #[cfg(target_arch = "x86")] {

so, hopefully, this marks the end of window build restoration journey... this and all previous prs will be backported as-is.

[ryoqun]

@yihau as you suggested at solana-labs/solana-program-library#4471 (comment), we can switch from building to downloading some existing spl tarball from somewhere. seems solang is taking this approach as shown below this file. I have no particular preference; but seeing the below code, needs some work for factoring the below download logic, etc (including testing on Windows). so, moar effort, imo.

So, overall, i think [patch]-ing is acceptable workaround for now. (after all, this won't be needed, once tokio is upgraded).

[ryoqun]

also, this is a bit too theoretical. but this bundled spl-token binary is used rather widely across various integrations. they seldom use cargo install .... so, i think using the same monorepo-pinned rust version is conceptually easier to reason about. admittedly, it's rare for rust to expose quite visible runtime/compile differences between versions. but this is possibility.

Also, it's more easy to ship new binary once rust found to contain critical security vuln (this again very unlikely)

[yihau]

sure. let's do this!

[codecov]

Codecov Report

Merging #31981 (7455754) into master (6b33ff8) will decrease coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #31981     +/-   ##
=========================================
- Coverage    81.9%    81.9%   -0.1%     
=========================================
  Files         760      760             
  Lines      207407   207407             
=========================================
- Hits       169958   169950      -8     
- Misses      37449    37457      +8     

[yihau]

🪖