conflicting `extern` and `export` declarations allowed in same compilation

[190n]

Zig Version

0.14.0

Steps to Reproduce and Observed Behavior

Try to compile code like the following (with zig build-obj):

export fn foo() u32 {
    return 123456;
}

export fn bar() u16 {
    const inner = struct {
        extern fn foo() u16;
    };
    return inner.foo();
}

It compiles successfully.

Expected Behavior

There should be an error because the declaration and definition of foo don't match.

[nektro]

hmm not sure how to feel about this. im very tempted to be in favor of this but i worry that having the compiler maintain the data necessary to do this and checking such a list would create a big source of contention once semantic analysis goes parallel. also this would only catch when the same zig compilation is the source of both the export and the extern, which was in the title but feels rare.

[nektro]

related #20654 which is more general

[190n]

this would only catch when the same zig compilation is the source of both the export and the extern, which was in the title but feels rare.

I think a usecase where this would help is if you have functions implemented in Zig to be called by C, plus a manually-written C header. If this were implemented then importing the header into Zig with translate-c and referencing all the function declarations would serve as a check that they are defined and declared with the same type.

[rohlem]

i worry that having [such a check] would create a big source of contention once semantic analysis goes parallel.

If such a check is a performance bottleneck, the compiler could still optionally provide it, controllable by CLI flag.
(IMO safe and slower is the better default, but that decision is up to maintainers, and can be made based on performance data.)