fix(compiler-cli): interpolatedSignalNotInvoked diagnostic #53585
Conversation
The diagnostic was catching the following case:
```ts
name = signal('Angular');
```
but not the following ones:
```ts
name = signal('Angular').asReadonly();
name = computed(() => 'Angular');
name!: Signal<string>
```
This was not catched in the tests because the type of `Signal` is different than the one actually used in core.
It turns out the real type forces the diagnostic to check both the `symbol.tsType.symbol` and the `symbol.tsType.aliasSymbol`.
jessicajaniuk
added
the
area: compiler
|
I see that you just added the If you want your PR to be merged, it has to pass all the CI checks. If you can't get the PR to a green state due to flakes or broken |
atscott
added
state: blocked
and removed
action: merge
atscott
added
action: merge
|
I see that you just added the If you want your PR to be merged, it has to pass all the CI checks. If you can't get the PR to a green state due to flakes or broken |
|
This PR was merged into the repository by commit 33b5707. |
The diagnostic was catching the following case:
```ts
name = signal('Angular');
```
but not the following ones:
```ts
name = signal('Angular').asReadonly();
name = computed(() => 'Angular');
name!: Signal<string>
```
This was not catched in the tests because the type of `Signal` is different than the one actually used in core.
It turns out the real type forces the diagnostic to check both the `symbol.tsType.symbol` and the `symbol.tsType.aliasSymbol`.
PR Close #53585
…3585) The diagnostic was catching the following case: ```ts name = signal('Angular'); ``` but not the following ones: ```ts name = signal('Angular').asReadonly(); name = computed(() => 'Angular'); name!: Signal<string> ``` This was not catched in the tests because the type of `Signal` is different than the one actually used in core. It turns out the real type forces the diagnostic to check both the `symbol.tsType.symbol` and the `symbol.tsType.aliasSymbol`. PR Close angular#53585
…3585) The diagnostic was catching the following case: ```ts name = signal('Angular'); ``` but not the following ones: ```ts name = signal('Angular').asReadonly(); name = computed(() => 'Angular'); name!: Signal<string> ``` This was not catched in the tests because the type of `Signal` is different than the one actually used in core. It turns out the real type forces the diagnostic to check both the `symbol.tsType.symbol` and the `symbol.tsType.aliasSymbol`. PR Close angular#53585
…3585) The diagnostic was catching the following case: ```ts name = signal('Angular'); ``` but not the following ones: ```ts name = signal('Angular').asReadonly(); name = computed(() => 'Angular'); name!: Signal<string> ``` This was not catched in the tests because the type of `Signal` is different than the one actually used in core. It turns out the real type forces the diagnostic to check both the `symbol.tsType.symbol` and the `symbol.tsType.aliasSymbol`. PR Close angular#53585
…3585) The diagnostic was catching the following case: ```ts name = signal('Angular'); ``` but not the following ones: ```ts name = signal('Angular').asReadonly(); name = computed(() => 'Angular'); name!: Signal<string> ``` This was not catched in the tests because the type of `Signal` is different than the one actually used in core. It turns out the real type forces the diagnostic to check both the `symbol.tsType.symbol` and the `symbol.tsType.aliasSymbol`. PR Close angular#53585
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The diagnostic was catching the following case:
but not the following ones:
See https://stackblitz.com/edit/stackblitz-starters-eqaius?file=src%2Fmain.ts for repro
What is the new behavior?
This was not caught in the tests because the type of
Signalis different than the one actually used in core. It turns out the real type forces the diagnostic to check both thesymbol.tsType.symboland thesymbol.tsType.aliasSymbol.Does this PR introduce a breaking change?
Other information