Compiler incorrectly handles error in parametric struct procedure parameter

[VestaKK]

Context

This is technically two bugs, but they're very related so I'll post them both here.

The first one is that the compiler goes into an infinite loop trying to handle a bugged procedure where a polymorphic struct parameter is not correctly specialised. This only happens when you try to access and assign a field inside that function parameter.

package main

Node :: struct($T: typeid) {
    data: T,
    next: ^Node(T),
}

bug_proc :: proc(node: ^Node) {
    node.next = nil // Puts compiler into infinite loop
}

main :: proc() {
    node := Node(int){}
    bug_proc(&node)
}

If you don't access the struct field, the function compiles incorrectly and runs:

package main

import "core:fmt"

Node :: struct($T: typeid) {
    data: T,
    next: ^Node(T),
}

bug_proc2 :: proc(node: ^Node) {
    fmt.println("This compiles and runs.") // Prints to console
}

main :: proc() {
    node := Node(int){}
    bug_proc2(&node)
}

odin report output:

    Odin:    dev-2024-04:f745fff64
    OS:      Windows 10 Professional (version: 22H2), build 19045.4291
    CPU:     AMD Ryzen 7 5800X 8-Core Processor
    RAM:     16330 MiB
    Backend: LLVM 17.0.1

Expected Behavior

Both should raise an error saying something along the lines of "Invalid use of a non-specialized polymorphic type 'Node' in procedure declaration", preventing the user from compiling the code.

Current Behavior

First code snippet goes into an infinite loop when compiled.
Second code snippet compiles bugged code and runs, printing into the console.

Failure Information (for bugs)

Steps to Reproduce

1. Copy and paste code snippets into separate odin projects
2. Do "odin build ."
3. First code snippet should hang and stay in an infinite loop
4. Second code snippet should compile and running it should print to the console

Failure Logs

No logs.

[mtarik34b]

For the first snippet, bisect reveals that the infinite loop was introduced in 6d4f30d. Before, an error was reported, though the missing specialisation wouldn't be detected, as can be seen in an older issue: #2982 (see error of fn3). The second snippet here kinda matches fn2 there.

[mtarik34b]

Should be fixed in d85c8f0?