Skip to content
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

Bad error message in SOA slice compound literals #3515

Open
jakubtomsu opened this issue Apr 29, 2024 · 2 comments
Open

Bad error message in SOA slice compound literals #3515

jakubtomsu opened this issue Apr 29, 2024 · 2 comments

Comments

@jakubtomsu
Copy link
Contributor

Context

        Odin:    dev-2024-03-nightly:4c35633e0
        OS:      Windows 10 Professional (version: 22H2), build 19045.4291
        CPU:     Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz
        RAM:     32681 MiB
        Backend: LLVM 17.0.1

Current Behavior

The current SOA slice initializer list errors are incorrect, unlike fixed arrays and dynamic arrays.

Foo :: struct {
    a: f32,
    b: f32,
}

foos := #soa[]Foo{{1, 2}, {3, 4}, {5, 6}}

This code results in:

Error: Invalid compound literal type '^f32'
        foos := #soa[]Foo{{1, 2}, {3, 4}, {5, 6}}
                          ^~~~~^
Error: Invalid compound literal type '^f32'
        foos := #soa[]Foo{{1, 2}, {3, 4}, {5, 6}}
                                  ^~~~~^
Error: Illegal compound literal, int cannot be used as a compound literal with fields
        foos := #soa[]Foo{{1, 2}, {3, 4}, {5, 6}}
                                          ^~~~~^

However, fixed and dynamic SOA arrays let the user know compound literals just aren't supported:

foos2 := #soa[2]Foo{{1, 2}, {3, 4}, {5, 6}}
Error: #soa arrays are not supported for compound literals
        foos2 := #soa[2]Foo{{1, 2}, {3, 4}, {5, 6}}
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
@jakubtomsu
Copy link
Contributor Author

This might be related to #3514 because the compiler attempts to use the internal pointers as members in the initializer list

@gingerBill
Copy link
Member

This issue and #3514 are actually unrelated since they can be handled completely differently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants