Unable to link regex crate with "-Z instrument-coverage" on x86_64-pc-windows-msvc

[ririsoft]

Hello,

Linking regex crate on x86_64-pc-windows-msvc fails when using -Z instrument-coverage.
The link succeeds when using -Z instrument-coverage=except-unused-functions

# Cargo.toml
[package]
name = "foobar"
version = "0.1.0"
authors = ["foobar"]
edition = "2018"

[dependencies]
regex = "1.5.4"

// main.rs
fn main() {
    use regex::Regex;
    let re = Regex::new(r"^\d{4}-\d{2}-\d{2}$").unwrap();
    assert!(re.is_match("2014-01-01"));
}

I expected to see this happen: linking successful.

Instead, this happened:

error: linking with `link.exe` failed: exit code: 1227

note: libmemchr-40eebd4a74e50761.rlib(memchr-40eebd4a74e50761.memchr.2b5ledse-cgu.14.rcgu.o) : fatal error LNK1227: conflicting weak extern definition for '_RINvNtNtNtCs838Isxeq56n_6memchr6memmem9prefilter11genericsimd14find_in_chunk3pEB8_'.  New default '.weak._RINvNtNtNtCs838Isxeq56n_6memchr6memmem9prefilter11genericsimd14find_in_chunk3pEB8_.default._RINvMNtCs93I3MPx9COt_4core5sliceSh13get_uncheckedINtNtNtB5_3ops5range7RangeTojEECs838Isxeq56n_6memchr' conflicts with old default '.weak._RINvNtNtNtCs838Isxeq56n_6memchr6memmem9prefilter11genericsimd14find_in_chunk3pEB8_.default._RINvMNtNtCs93I3MPx9COt_4core3ptr9const_ptrPh4castuECs838Isxeq56n_6memchr' in libmemchr-40eebd4a74e50761.rlib(memchr-40eebd4a74e50761.memchr.2b5ledse-cgu.3.rcgu.o)

Meta

rustc --version --verbose:

rustc +nightly --version --verbose       
rustc 1.54.0-nightly (3e99439f4 2021-05-17)
binary: rustc
commit-hash: 3e99439f4dacc8ba0d2ca48d221694362d587927
commit-date: 2021-05-17
host: x86_64-pc-windows-msvc
release: 1.54.0-nightly
LLVM version: 12.0.1

[richkadel]

I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.)

So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug...

Thanks and sorry for the churn... 😄

[ririsoft]

I'm adding a note here because my brain gets confused by github's bold-text "mentioned this issue" notes. I see the "No counters provided the source-hash" and jump to the wrong conclusion that this is related. (I think I've done this more than once.)

So, NOTE TO SELF, this issue is NOT related to the "No counters provided the source hash" bug...

Thanks and sorry for the churn... smile

Even worth, I suspect you deleted your previous comment 😋. In my mail box I got from github on your behalf, I have the message "This should be fixed. There was a brief window in the nightly builds (less than a week I think) where this was a known bug. It was resolved."), but I have no trace of it in the conversation, so I am even more lost with just above message. If you wish you can edit messages instead of deleting. Users can see that your message was edited and they can access edition history to see what changed.

But considering all the effort you are giving with instrument coverage, and how important this is to Rust (in my humble opinion), you are fully forgiven 😄

[EFanZh]

I see instrument-coverage is about to be stabilized: #90132. Will this issue be solved before stabilization?

[richkadel]

@wesleywiser I rarely have a useable windows configuration for debugging coverage. Any chance you can look into this?

Also note the theory and workaround suggested in microsoft/windows-rs#1006 (comment)

I think stabilizing the flag does not imply every edge case is understood and resolved so it may not block stabilization, but I haven't had any time to look into this one since it was filed. I suspect it has to do with generating function symbols for unused functions in the covmap generation code but not sure if something else is involved (macros were mentioned in the linked comment).

Since I'm out for 3 weeks I'm not going to have a chance to look at this for at least that long. Seems very rare too.

Thanks!

Cc: @tmandry

[wesleywiser]

@richkadel Yep, I'll take a look this week!

[BlackHoleFox]

Seems very rare too.

I hit this with the webpki crate today as well, so any project with rustls in its tree (ureq for me) may hit it. That said, only three (known) cases isn't a lot of evidence towards rarity or against it...