fix(validation): reject THIS.<member> without dereference

[ghaith]

Summary

• Validator now emits E120 when a member access uses THIS as a base without an explicit ^ deref (e.g. THIS.field instead of THIS^.field). Mirrors the existing SUPER-deref rule.
• Without this guard, THIS.<field> slipped through both plc check and plc build and crashed codegen with Builder error: GEP pointee is not a struct (pointee: "ptr", index: 1).
• E120's markdown body already documented this rule; only the validator site was missing.
• Also dedupes exact-duplicate diagnostics in Validator::push_diagnostic (boyscout). Lowering occasionally clones a receiver AST into multiple positions in the post-lowered tree (operator chain + synthesised self argument), which caused this new THIS check and the existing SUPER-deref check to render twice for the same span. Dedup is keyed on Diagnostic's existing PartialEq (code + message + locations + sub-diagnostics).

Fixes #1728

Test plan

• tests/lit/single/oop/this_member_access_without_deref_errors.st — runs plc -c on the minimal repro, asserts E120 fires, asserts no binary is produced.
• this_member_access_without_deref_is_an_error unit test in src/validation/tests/this_keyword_validation_tests.rs with inline snapshot.
• cargo test --workspace clean (no snapshot churn from the dedup).
• cargo xtask lit clean (377 tests; 359 pass, 14 XFAIL, 4 unsupported).
• cargo fmt --all and cargo clippy --workspace -- -Dwarnings clean.

🤖 Generated with Claude Code

[github-actions]

Build Artifacts

🐧 Linux

Artifact	Link	Size
deb-aarch64	Download	31.0 MB
plc-aarch64	Download	43.6 MB
deb-x86_64	Download	38.5 MB
schema	Download	0.0 MB
stdlib	Download	32.4 MB
plc-x86_64	Download	43.7 MB

From workflow run

🪟 Windows

Artifact	Link	Size
stdlib.lib	Download	4.3 MB
stdlib.dll	Download	0.1 MB
plc.exe	Download	38.5 MB

From workflow run

[riederm]

hey, just checking in once in a while to see how the AI task-force is doing ;-)
and left a question here 😆

[riederm]

I wonder if listing all these special cases here is the correct way to go?

Aren't (almost all of) these cases caught by one generic type-check? like see if the member could be resolved under this base? Or is the resolver actually able to find anything for Member in these cases?

What I mean is, should these two lines maybe give the same error-message?

VAR_GLOBAL
    p_fb : POINTER TO FB ...;
END_VAR

FUNCTION_BLOCK fb
...
METHOD m : DINT
    THIS.a;    // cannot access a on type pointer to fb
    p_fb.a;     // cannot access a on type pointer to fb
END_METHOD

[ghaith]

I changed the logic for both this and super (and normal pointers) to get a clearer message, now we report that you should dereference the pointer before accessing a member.

[riederm]

not sure if my question made it through 😆 . I was asking if the root of the problem is the type-resolver which forces you to such differentiated checks. (the problem as in, why are such specific checks necessary, while I expected the type-resolver to see that problem clearly).

i tested this quickly:

    #[test]
    fn super_and_this() {
        let src = 
            "
        FUNCTION_BLOCK parent
        VAR
            y : INT := 20;
        END_VAR
        END_FUNCTION_BLOCK

        FUNCTION_BLOCK child EXTENDS parent
        VAR
            x  : INT := 10;
            px : POINTER TO child;
        END_VAR

            {{px^}.x};
            {{px}.x};

            {{this^}.x} := 50;
            {{this}.x} := 50;

            {{super}.x};
            {super^.x};  // super^ seams to be special?! the expression collector fails to collect super^
            
        END_FUNCTION_BLOCK
        ";

        let resolves = test_resolve(src).unwrap();
        assert_snapshot!(resolves, @r###"
             EXPR | TYPE         | HINT 
        ----------+--------------+------
            px^.x | INT          | -          - OK
              px^ | child        | -          - OK
             px.x | -            | -          - OK
               px | __child_px   | -          - OK
          this^.x | INT          | -          - OK
            this^ | child        | -          - OK
           this.x | INT          | -          - surprising!! 
             this | child.__THIS | -          - OK
          super.x | INT          | -          - surprising!!
            super | -            | -          - surprisnig!! (would have expected similar behavior like this)
         super^.x | INT          | -          - OK
        "###);
    }

it is also strange that the expression-collector seams to fail to collect super^ as an expression and type-resolve it. adding {super^} fails while {px^} and {this^} work fine - very strange.

❓ so what I wanted to discuss was, is this differentiation of a px, this and super intended and actually helpful?

[ghaith]

not sure if my question made it through 😆 . I was asking if the root of the problem is the type-resolver which forces you to such differentiated checks. (the problem as in, why are such specific checks necessary, while I expected the type-resolver to see that problem clearly).

i tested this quickly:

    #[test]
    fn super_and_this() {
        let src = 
            "
        FUNCTION_BLOCK parent
        VAR
            y : INT := 20;
        END_VAR
        END_FUNCTION_BLOCK

        FUNCTION_BLOCK child EXTENDS parent
        VAR
            x  : INT := 10;
            px : POINTER TO child;
        END_VAR

            {{px^}.x};
            {{px}.x};

            {{this^}.x} := 50;
            {{this}.x} := 50;

            {{super}.x};
            {super^.x};  // super^ seams to be special?! the expression collector fails to collect super^
            
        END_FUNCTION_BLOCK
        ";

        let resolves = test_resolve(src).unwrap();
        assert_snapshot!(resolves, @r###"
             EXPR | TYPE         | HINT 
        ----------+--------------+------
            px^.x | INT          | -          - OK
              px^ | child        | -          - OK
             px.x | -            | -          - OK
               px | __child_px   | -          - OK
          this^.x | INT          | -          - OK
            this^ | child        | -          - OK
           this.x | INT          | -          - surprising!! 
             this | child.__THIS | -          - OK
          super.x | INT          | -          - surprising!!
            super | -            | -          - surprisnig!! (would have expected similar behavior like this)
         super^.x | INT          | -          - OK
        "###);
    }

it is also strange that the expression-collector seams to fail to collect super^ as an expression and type-resolve it. adding {super^} fails while {px^} and {this^} work fine - very strange.

❓ so what I wanted to discuss was, is this differentiation of a px, this and super intended and actually helpful?

Fair i'll check why they do differ, i think when super and this were implemented they were special cases but i need to check again how exactly they behave. I misunderstood the initial request, I thought you wanted a clearer message there (which I think is also cool)