-
-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allocator usage causes zls inline types to get very confused #1841
Comments
I think I got to the root of this. The cause is caching of the node types (link to code). The cache does not take into account the fact that the return type depends on the arguments to the function. Here is the minimal reproduction: fn foo(comptime T: type) T {
return 42;
}
const bar = foo(u1); // hints `u1`
const baz = foo(u2); // hints `u1` In this code, the type of Now what could be the solution here?
|
Another observation: the reason why hover works most of the time is because the fn arr(comptime T: anytype) []T {
return &[_]T{};
}
// The deeper `arr` is evaluated, the outer `arr` is from cache
// should be [][]u1, but both hint and hover is []u1
pub const hover = arr(@TypeOf(arr(u1)));
|
Zig Version
0.12.0-dev.3439+31a7f22b8
Zig Language Server Version
0.12.0-dev.496+96eddd0
Client / Code Editor / Extensions
VSCode with official extension
Steps to Reproduce and Observed Behavior
Put this code into a file
You'll see ZLS incorrectly show the type of
two
as[]u16
This behaviour gets very weird when its spread across multiple functions
https://github.com/zigtools/zls/assets/34501060/c0f9498b-a24e-403b-921e-b026b93a516c
Expected Behavior
The type of all the alloc calls is correctly resolved
Relevant log output
No response
The text was updated successfully, but these errors were encountered: