Possible Bug: Incomplete Function Analysis with refAllDecls

[kython28]

Zig Version

0.14.0-dev.3267+59dc15fa0

Steps to Reproduce and Observed Behavior

I'm currently migrating my codebase from Zig 0.13.0 to 0.14.0-dev.3267+59dc15fa0, and I've noticed what might be unexpected behavior in the semantic analysis of functions.

In my test file, I'm using std.testing.refAllDecls which, as far as I understand, should trigger semantic analysis for all declarations. While this generally works as expected, I've observed that some functions seem to be skipped during analysis.

To reproduce:

1. Check my repository's test file at tests/main.zig
2. Notice the line std.testing.refAllDecls(opencl.errors); which should analyze all declarations (src/errors.zig)
3. Specifically, there's a public function translate_opencl_error_for_all_fields that contains:

const opencl_error_fields = @typeInfo(opencl_error_enum).Enum.fields;

This should trigger an error as the correct syntax should be:

const opencl_error_fields = @typeInfo(opencl_error_enum).@"enum".fields;

4. The semantic analysis also fails to detect this issue when trying to reference it with _ = &opencl.errors.translate_opencl_error_for_all_fields
5. The only way to trigger the analysis is by directly calling the function: opencl.errors.translate_opencl_error_for_all_fields(0);

Question: Shouldn't refAllDecls trigger semantic analysis for all declarations? Is this intended behavior or potentially a bug?

I'm not entirely sure if this is a bug or if I'm misunderstanding how refAllDecls is supposed to work. Any clarification would be appreciated.

Expected Behavior

The compiler should detect and report that .Enum is an invalid field access or something like that

[rohlem]

3. Specifically, there's a public function translate_opencl_error_for_all_fields that contains:

const opencl_error_fields = @typeInfo(opencl_error_enum).Enum.fields;

This should trigger an error as the correct syntax should be:

const opencl_error_fields = @typeInfo(opencl_error_enum).@"enum".fields;

4. The semantic analysis also fails to detect this issue when trying to reference it with _ = &opencl.errors.translate_opencl_error_for_all_fields

5. The only way to trigger the analysis is by directly calling the function: opencl.errors.translate_opencl_error_for_all_fields(0);

The issue here is relatively fundamental: The function has an anytype parameter.
This means the compiler internally flags it as "generic", because it will be instantiated based on comptime information provided by a callsite. (The same happens for functions with comptime parameters.)

Currently, generic functions aren't analyzed at all when they are referenced with & syntax (the resulting type is a pointer to a comptime-only function, so can never escape to runtime unless called).
Because they aren't analyzed at all, even issues that exist in all possible instantiations aren't found and reported.

In status-quo I believe this to be documented/intentional behavior, so not a bug.
There's been issues about potentially improving behavior before, f.e. #16806 and all transitively linked ones.

[kython28]

Hello, also happen here https://github.com/kython28/zig-opencl/blob/2f068215924440326fecb70d45d5e63b48fcfedf/src/buffer.zig#L329

[rohlem]

Yes, in that case it's due to the comptime parameter comptime T: type.
EDIT: If you want them analyzed, the easiest way would be to call them in a test case that is referenced.

[kython28]

Well yes, but I think It could be analyzed, no? 🙁

Because the result of @typeInfo is potentially known and it is known that .Pointer does not exist.