Not sure whether it will impact anyone in practice, but I've yanked windows-targets 0.52.1 and published 0.52.2 with this fix just to be sure.

I'm seeing this exact error using 0.52.2. My build now passes if I downgrade to 0.52.0 (cargo update --package windows-targets --precise 0.52.0).

I noticed that Cargo doesn't reliably grab the latest when an older version is yanked that you happen to already have downloaded. My issue was resolved after I forced a download of 0.52.2 and after that it just worked as before. For example, this will force your local cache to get updated:

[dependencies.windows-targets]
version = "0.52.2"

After running Cargo, you can remove this dependency and its cache should be updated. This seems like a Cargo or crates.io bug but I'm not sure.

Presumably you can also run cargo update --package windows-targets --precise 0.52.2

yes, if a Cargo.lock is present whatever version was in there will be used. The cargo update dance needs to be done to update dependencies.

But this does not solve my issue.

My problem occurred when pushing a branch that triggered a CI: since I don't have a lock file committed, cargo will use the latest versions of all (semver compatible) dependencies. Meaning it will use windows-targets 0.52.2. That version is problematic in my builds: I get the macro expansion error (no rules expected the token '#').

I then tried to downgrade to 0.52.0. I did report that it worked, but actually I get a different error:

❯ cargo update --package windows-targets --precise 0.52.0
 Downgrading windows-targets v0.52.1 -> v0.52.0
❯ cargo build
   Compiling ********* v0.7.1
error: linking with `link.exe` failed: exit code: 1181
  |
  = note: "[...]"
  = note: LINK : fatal error LNK1181: cannot open input file 'windows.0.52.0.lib'

On my local windows vm I tried to update to 0.52.2 explicitly but surprisingly it failed:

❯ cargo update --package windows-targets --precise 0.52.2
error: no matching package named `windows-targets` found
location searched: registry `crates-io`
required by package `windows-sys v0.52.0`
    ... which satisfies dependency `windows-sys = "^0.52.0"` (locked to 0.52.0) of package `is-terminal v0.4.12`
    ... which satisfies dependency `is-terminal = "^0.4.0"` (locked to 0.4.12) of package `env_logger v0.10.2`
    ... which satisfies dependency `env_logger = "^0.10.0"` (locked to 0.10.2) of package `****`

Modifying the Cargo.toml directly as suggested gives a slightly different error:

❯ cargo build
error: failed to select a version for the requirement `windows-targets = "^0.52.2"`
candidate versions found which didn't match: 0.52.1, 0.52.0, 0.48.5, ...
required by package `***`
perhaps a crate was updated and forgotten to be re-vendored?

This is mysterious...

You may also be hitting this issue: #2870

I just checked my logs and CI was using 0.52.1 🤔

I guess an updated version (0.52.3?) will be released with the linking issue fixed (#2870). I'll see if that version helps out.

Yep 0.52.3 is on its way.

0.52.3 has now been published - let me know if you have any further issues.

I've relaunched my CI job (still without lock file) and it picked up 0.52.3; it now builds without issue.

Thanks a lot!! 👍

@kennykerr It seems since this was shipped I'm seeing doc failures for windows_sys in our CI on rustc 1.63 (our MSRV):

error: "D:\a\ldk-node\ldk-node\target\doc\windows_sys\all.html": The system cannot find the path specified. (os error 3)

error: couldn't generate documentation: I/O error

error: could not document `windows-sys`