Build fails under Windows locally: unresolved import winapi::shared::winerror

[hauserx]

Extracted from #62

For some reason was not able to build bazel-lsp on current HEAD though, running git-bisect shows this PR as culprit: #69

I am getting an errors like:

error[E0432]: unresolved import `winapi::shared::winerror`
   --> ../rules_rust~~_crate~~~crate~crates__dirs-sys-next-0.1.2/src/lib.rs:131:9
    |
131 |     use winapi::shared::winerror;
    |         ^^^^^^^^^^^^^^^^^^^^^^^^ no `winerror` in `shared`
    |

It works on CI but fails on my machine, something seems wrong here.

Adding below lines to Cargo.toml helps in my case:

[target.'cfg(windows)'.dependencies]
winapi = { version = "0.3.9", features = ["winerror", "combaseapi", "knownfolders", "shlobj", "shtypes", "winbase", "winnt", "wincon", "handleapi", "consoleapi" ] }

Bisect on rules_rust points to this PR as one that changed behavior here: bazelbuild/rules_rust#3034

[cameron-martin]

I get a different error when building on windows on my local machine:

ERROR: C:/b/ziqloc7w/external/protobuf~/src/google/protobuf/BUILD.bazel:462:11: Compiling src/google/protobuf/wire_format_lite.cc [for tool] failed: undeclared inclusion(s) in rule '@@protobuf~//src/google/protobuf:protobuf_lite':
this rule is missing dependency declarations for the following files included by 'src/google/protobuf/wire_format_lite.cc':
  'bazel-out/protobuf~/x64_windows-opt-exec-ST-d57f47055a04/bin/src/google/protobuf/_virtual_includes/protobuf_lite/google/protobuf/port.h'
../protobuf~/src/google/protobuf/wire_format_lite.cc(669): warning C4068: unknown pragma 'clang'
../protobuf~/src/google/protobuf/wire_format_lite.cc(711): warning C4068: unknown pragma 'clang'

A git bisect shows that 16f99a9 is also the culprit, but presumably for a different reason of also updating protobuf.

Looks like at least one other user has reported this: protocolbuffers/protobuf#19410 (comment)

[hauserx]

Does it go away if you execute "bazel clean" and retry? I think I have seen this issue at some point as well, but it maybe related to .d file being cached and not recreated b/c bazel thought it the action does not need to be rerun (e.g. because only something like --experimental_sibling_repository_layout flag changed).

[hauserx]

For the original issue, I think it maybe duplicate of bazelbuild/rules_rust#2946, the winapi is only runtime dependency in the graph. It through e.g. starlark_syntax --[build-dependencies]--> lalrpop -> ascii-canvas -> term -> winapi as can be checked with cargo tree.

Not sure why it works on CI though yet, but reverting this line in the rules_rust helps locally as well (although it seems it's wrong thing to do):
https://github.com/bazelbuild/rules_rust/pull/3034/files#diff-6ed19f8951b26734a47ca9a095e9e2e86869c606e178e93b2629d2bca486025bL10

Unfortunately each build on Windows takes minutes.

[cameron-martin]

After a bazel clean, building and testing on my windows machine works fine. It's weird we're seeing different behaviour, and it's also worrying that incremental builds don't work properly on windows.

[hauserx]

Closing it as it's enough to remove target/ directory locally if one created it. Created PR to rules_rust with permanent fix.