feat(ts/analyzer): handle private field access in derived class

[littledivy]

Handle private name field access in derived class.

class Base {
    #prop: number = 123;
    static method(x: Derived) {
        x.#prop
    }
}

class Derived extends Base {
    static method(x: Derived) {
        x.#prop;
    }
}

error[TS18013]: DebugContext(
    context: tried to access property of an object to calculate type of a member expression
    context: tried to access property of an object (instanceof  Derived;, id_ctx = Var)
    Prop=Private(PrivateName { span: Span { lo: BytePos(168), hi: BytePos(173), ctxt: #0 }, id: prop#0 })
    context: tried to access property of an object (Derived;, id_ctx = Var)
    Prop=Private(PrivateName { span: Span { lo: BytePos(168), hi: BytePos(173), ctxt: #0 }, id: prop#0 })
    context: tried to access property of an object (this;, id_ctx = Var)
    Prop=Private(PrivateName { span: Span { lo: BytePos(168), hi: BytePos(173), ctxt: #0 }, id: prop#0 })
    CannotAccessPrivatePropertyFromOutside {
        span: Span {
            lo: BytePos(
                166,
            ),
            hi: BytePos(
                173,
            ),
            ctxt: #0,
        },
    },
)
  --> a.ts:10:9
   |
10 |         x.#prop;
   |         ^^^^^^^

[littledivy]

@kdy1 I'm not sure what required_error error mean relative to matched_error.

So far I've understood that (correct me if im wrong):

• extra_errors are the ones that we should not be emiting but we do. This should go down.
• matched_errors are the ones that matched expected errors. This still counts if there are extra_errors in a test case (?). This should go up.

matched_error - required_error = 5545 - 4150 = 1395 🤔

[kdy1]

required_error means we have to emit those error for 100% parity with tsc

[kdy1]

But well, I think we should document it somewhere, or change the name

[oadam]

you should rename it to missing_error

[kdy1]

Oops I think we need a better way to track tsc stats.
It was fine for me because I was the only person working on stc, but it will make lots of rebasing necessary.
Any ideas?

[kdy1]

I'm focusing on removing false-positive, so the increase of extra_error isn't acceptable

[oadam]

Oops I think we need a better way to track tsc stats. It was fine for me because I was the only person working on stc, but it will make lots of rebasing necessary. Any ideas?

This could be a plan :

1. stop committing the error counts
2. at the end of the github action build, publish the error counts as a github action artifact
3. compare your stats to the stats contained in the artifacts of the last successful build of the main branch
4. publish a comment on the PR comparing your stats to those of the main branch