tree 6c5151d72b81da51b035a1c05846843558f89fbb
parent 8b0f6441225dcf80b0643b97c8b440caf4efeb84
author scentini <rosica@google.com> 1657195040 +0000
committer GitHub <noreply@github.com> 1657195040 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJixsogCRBK7hj4Ov3rIwAAGWAIAEENTHdkeBUpDS3zCV6gH2VN
 zyFAyuJXsO2+42ExNh4QUBJyyZHVOGZ3WYcYo/BdoQZ3bEugncXc1megDaVH7DKk
 pv/TZYssx+m51uaXNSetPWL21h5lzuH92xRRN5smDbrwD+UnZ5xUcW9pmCE3FQbo
 RasvIf1vcSu/CSxdls05+sZ3V8ZW7p2mohe7T19HWxfPMagyzHyrHOOCKxgbwt+X
 KwJyfp6xzuNr+eQ4JS4RqFuGgzUzEJDZpKZAcNdCQPk9WOQen1g0fttg3W+TIh5N
 Nv6rLWBZ+jTlORRH/hbhpdghlSUZHYSMGJijP0XPeFB8r+j9ZDr6ykK/k3bTU6Y=
 =MQgR
 -----END PGP SIGNATURE-----
 

Have rust_test put its compilation outputs in a subdirectory (#1434)

This is supposed to fix the long standing Windows flakiness as described in https://github.com/bazelbuild/rules_rust/pull/1427#issuecomment-1171940333

Initially I thought it's an issue with `rustdoc_test`, however the actual issue is that `rust_binary` and its `rust_test` have the same crate name and generate the same intermediary `.o` files. For sandboxed builds this is not an issue, as the actions are isolated, however, we have a race condition in non-sandboxed builds (Windows):

Let's consider the following build:
```
bazel build --spawn_strategy=standalone \
    //test/unit/rustdoc:bin_with_transitive_proc_macro \
    //test/unit/rustdoc:bin_with_transitive_proc_macro_test
```

The `bin_with_transitive_proc_macro` compile action will create the following intermediate file: `bazel-out/k8-fastbuild/bin/test/unit/rustdoc/bin_with_transitive_proc_macro.bin_with_transitive_proc_macro.573369dc-cgu.2.rcgu.o`, as will the `bin_with_transitive_proc_macro_test` action. These two files differ slightly (as the second action is for a test), namely the `bin_with_transitive_proc_macro` output has the following symbols:

```
0000000000000000 T main
0000000000000000 t _ZN30bin_with_transitive_proc_macro4main17hfc292cc42314e131E
                 U _ZN3std2rt10lang_start17h1dbc829c47cd61d9E
```

while the `bin_with_transitive_proc_macro_test` `.o` output looks like this:
```
0000000000000000 T main
0000000000000000 t _ZN30bin_with_transitive_proc_macro4main17h28726504dc060f8dE
                 U _ZN3std2rt10lang_start17h1dbc829c47cd61d9E
                 U _ZN4test16test_main_static17h37e3d88407f5b40fE
```

Now, when the two actions run in parallel, it can happen that `bin_with_transitive_proc_macro` creates the output, and `bin_with_transitive_proc_macro_test` overwrites it. Then, at linking time for `bin_with_transitive_proc_macro`, `rustc` will complain:
```
note: ld.lld: error: undefined symbol: test::test_main_static::h37e3d88407f5b40f
```
This is because `bin_with_transitive_proc_macro` is not a test and as such is not linked against `libtest`.

This PR fixes the issue by directing the compilation outputs of `rust_test` to be under a `test-{hash}` directory.