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

Fix for windows-targets::link doc compatibility #2868

Merged
merged 2 commits into from
Feb 22, 2024
Merged

Conversation

kennykerr
Copy link
Collaborator

Just making sure we preserve link macro compatibility in some cases as shown in this test failure:

https://github.com/microsoft/windows-rs/actions/runs/8005925420/job/21866485024

@kennykerr kennykerr changed the title Fix for windows-target link doc compat Fix for windows-targets::link doc compat Feb 22, 2024
@kennykerr kennykerr changed the title Fix for windows-targets::link doc compat Fix for windows-targets::link doc compatibility Feb 22, 2024
@kennykerr kennykerr merged commit 428a7ca into master Feb 22, 2024
66 checks passed
@kennykerr kennykerr deleted the targets-doc branch February 22, 2024 15:10
@kennykerr
Copy link
Collaborator Author

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.

@nbigaouette
Copy link

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).

@kennykerr
Copy link
Collaborator Author

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.

@kennykerr
Copy link
Collaborator Author

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

@nbigaouette
Copy link

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...

@kennykerr
Copy link
Collaborator Author

You may also be hitting this issue: #2870

@nbigaouette
Copy link

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.

@kennykerr
Copy link
Collaborator Author

Yep 0.52.3 is on its way.

@kennykerr
Copy link
Collaborator Author

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

@nbigaouette
Copy link

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!! 👍

@tnull
Copy link

tnull commented Feb 26, 2024

@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`

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

Successfully merging this pull request may close these issues.

3 participants