possible address sanitizer bug

[netizen-a]

I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: dylink_macro and dylink. On dylink_macro there is a procedural macro called dylink, which is named the same as my dylink crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case.

error[E0519]: the current crate is indistinguishable from one of its dependencies: it has the same crate-name `dylink_macro` and was compiled with the same `-C metadata` arguments. This will result in symbol conflicts between the two.
   --> src/lib.rs:104:9
    |
104 | pub use dylink_macro::dylink as dylink;
    |         ^^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `crate::dylink`
  --> src/vulkan.rs:50:2
   |
50 |     crate::dylink(any(name = "libvulkan.so.1", name = "libvulkan.so"))
   |     ^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

cargo +nightly version:

cargo 1.71.0-nightly (569b648b5 2023-05-05)

I included the full error output in a file below

error.log

[taiki-e]

If you use sanitizers you need to pass the --target flag, but I guess you missed it.

See also documentation of -Z sanitizer:

Build scripts and procedural macros

Use of sanitizers together with build scripts and procedural macros is technically possible, but in almost all cases it would be best avoided. This is especially true for procedural macros which would require an instrumented version of rustc.

In more practical terms when using cargo always remember to pass --target flag, so that rustflags will not be applied to build scripts and procedural macros.

[netizen-a]

Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!

[m-ou-se]

Re-opening because the error is very confusing. See also #111349

[m-ou-se]

On rustc 1.70.0-nightly (a266f1199 2023-03-22) the error is:

error: undefined symbol: __asan_option_detect_stack_use_after_return

which isn't great, but at least suggests some issue related to asan.

On rustc 1.70.0-nightly (1459b3128 2023-03-23) the error is:

error[E0519]: the current crate is indistinguishable from one of its dependencies: it has the same crate-name `inline_python_macros` and was compiled with the same `-C metadata` arguments. This will result in symbol conflicts between the two.

Which is very confusing.

#109213 was merged between those two versions and changes in which cases E0519 is emitted.

ping @oli-obk who wrote that PR.