{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":107854570,"defaultBranch":"main","name":"angular","ownerLogin":"JoostK","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2017-10-22T09:58:30.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/123679?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1710105327.0","currentOid":""},"activityList":{"items":[{"before":"96fbc35ec744dd819897471c9bca7bae32878b1b","after":"d66890ac81d7eee2b94c670a36a0d5fe2f99361d","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-21T20:11:41.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"feat(compiler-cli): enable narrowing of signal reads in templates\n\nSignal reads in Angular templates don't currently benefit from TypeScript's\nnarrowing capabilities, since function calls are not eligle for type narrowing.\nThis is unfortunate since Angular templates should not be updating signal\nvalues, such that narrowing would be a safe operation.\n\nIdeally there would be a way for TypeScript to enable type-narrowing of signal\nreads, but this is unfortunately not possible today.\n\nVarious potential designs have been explored to support type-narrowing of\nsignal reads in the compiler's Type-Check Block (TCB):\n\n1. Assign call expressions to a local variable in the TCB, rewriting further\n   usages of the same signal to the local variable instead. This way,\n   TypeScript is able to apply narrowing of this local variable that all\n   subsequent reads are then able to leverage.\n\n2. Augment the `Function` declaration with a getter field corresponding with\n   the function's return type, then emitting call expression as property reads\n   using this augmented getter.\n\nAlthough approach 2 simplifies the TCB emit compared to 1, it could not be made\nto work in practice as the `Function` declaration itself doesn't have any\ngeneric type to extract the return type from.\n\nInstead, this commit implements approach 1. The primary known design limitation\nof this approach arrises with optional chaining, where the call expressions\nend up with different identities to prevent reusing an earlier variable\ndeclaration for the call expression. For example, consider the following template:\n\n```\n@if (person()?.address()) {\n\t<app-address [address]=\"person().address()\">\n}\n```\n\nNormally in TypeScript this would be accepted (provided that the call\nexpressions are just property reads), but our referencing approach does not\nconsider the signal reads of `address()` to have the same receiver. You may\nthink this limitation can be overcome by always identifying property reads\nas equivalent to their safe counterpart (i.e. always treating `.` as `?.`) but\ndoing so would introduce false negatives in the negated case:\n\n```\n@if (!person()?.address()) {\n\t<app-address [address]=\"person().address()\">\n}\n```\n\nIf the `person().address()` was to correspond with `person()?.address()` to\nmake it align with the condition, then no error would be reported that\n`person()` may be `null`. To avoid such false negatives in template diagnostics\nthis commit is being conservative with optional chains, where narrowing is not\nachieved as would be the case with property reads. Perhaps there may be ways of\nimproving this in the future.\n\nAnother side effect of this change is that diagnostics won't be reported within\nexpressions that have been substituted with a reference. Consider:\n\n```\n@if (person().nam()) {\n\t{{ person().nam() }}\n}\n```\n\nSince the secondary occurrence of `person().nam()` is being substituted for the\nlocal variable that is assigned within the `@if`-condition, the typo in `nam()`\nis not reported for the expression in the block.","shortMessageHtmlLink":"feat(compiler-cli): enable narrowing of signal reads in templates"}},{"before":"5ad7869fc9bedaeb83695f24a8e11c05be0e3f6a","after":"96fbc35ec744dd819897471c9bca7bae32878b1b","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-21T20:01:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"feat(compiler-cli): simulate narrowing of signal reads in templates","shortMessageHtmlLink":"feat(compiler-cli): simulate narrowing of signal reads in templates"}},{"before":"c5cf68a5ed1d226a6894999463ac55d32856ca8f","after":"5ad7869fc9bedaeb83695f24a8e11c05be0e3f6a","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:17:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(compiler-cli): effective narrowing of signal reads in templates\n\nThis commit is an experiment to see how the template type-check block\ncan be modified to support effective narrowing of signal reads.\n\nThe prototype exposes one problem in particular: calling a type guard method\nno longer narrows according to the type-guard, as the method call is indirected\nthough an additional variable.\n\nOther problems with this approach is that diagnostics will not be reported for\nall usages, given that identical call expressions are deduplicated into a single\ncall expression.\n\nThe implementation of this prototype is not as efficient as it could be.\nIn particular, computing the identifier of a call expression does not leverage\na potentially existing identifier for another call expression in its LHS.","shortMessageHtmlLink":"refactor(compiler-cli): effective narrowing of signal reads in templates"}},{"before":"18c45d5aeecb019fe8ec57e1b6d4743593e46b0c","after":"c5cf68a5ed1d226a6894999463ac55d32856ca8f","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:12:26.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(compiler-cli): effective narrowing of signal reads in templates\n\nThis commit is an experiment to see how the template type-check block\ncan be modified to support effective narrowing of signal reads.\n\nThe prototype exposes one problem in particular: calling a type guard method\nno longer narrows according to the type-guard, as the method call is indirected\nthough an additional variable.\n\nOther problems with this approach is that diagnostics will not be reported for\nall usages, given that identical call expressions are deduplicated into a single\ncall expression.\n\nThe implementation of this prototype is not as efficient as it could be.\nIn particular, computing the identifier of a call expression does not leverage\na potentially existing identifier for another call expression in its LHS.","shortMessageHtmlLink":"refactor(compiler-cli): effective narrowing of signal reads in templates"}},{"before":"36a7d75f08bb274a02fab785244a150a2acaf717","after":"18c45d5aeecb019fe8ec57e1b6d4743593e46b0c","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:09:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"d14896a150574f5d669eb7bca3143162dfecb1e4","after":"36a7d75f08bb274a02fab785244a150a2acaf717","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:08:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"441e4b98f79ef73f5436e437b4dbbd2fb0511a6f","after":"d14896a150574f5d669eb7bca3143162dfecb1e4","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:04:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"3a7d787a491d769fbb7ea82b6802b99942851b40","after":"441e4b98f79ef73f5436e437b4dbbd2fb0511a6f","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:04:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"de3ed438ddfff8b2b96750183a64f27a564f11aa","after":"3a7d787a491d769fbb7ea82b6802b99942851b40","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T20:03:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"be357e0f3282e5c5fd62bc85b773c6d172fe49db","after":"de3ed438ddfff8b2b96750183a64f27a564f11aa","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T19:45:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"e6ea4b5aba7a2b74c5531a465a180e589cf85cae","after":"be357e0f3282e5c5fd62bc85b773c6d172fe49db","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-14T19:44:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"b081fd0c3160c1dbe455b7d1a180a82b91f94ddd","after":"e6ea4b5aba7a2b74c5531a465a180e589cf85cae","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-02T21:42:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"2df7716e5d1c97c262309f5dea5a9e0d4fac0d34","after":"b081fd0c3160c1dbe455b7d1a180a82b91f94ddd","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-02T21:10:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fixup! refactor(compiler-cli): effective narrowing of signal reads in templates WIP","shortMessageHtmlLink":"fixup! refactor(compiler-cli): effective narrowing of signal reads in…"}},{"before":"8c2e98ff757a2367797e8dc13b27a5b3d796f1f8","after":"2df7716e5d1c97c262309f5dea5a9e0d4fac0d34","ref":"refs/heads/signals-ttc","pushedAt":"2024-04-01T16:22:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(compiler-cli): effective narrowing of signal reads in templates\n\nThis commit is an experiment to see how the template type-check block\ncan be modified to support effective narrowing of signal reads.\n\nThe prototype exposes one problem in particular: calling a type guard method\nno longer narrows according to the type-guard, as the method call is indirected\nthough an additional variable.\n\nOther problems with this approach is that diagnostics will not be reported for\nall usages, given that identical call expressions are deduplicated into a single\ncall expression.\n\nThe implementation of this prototype is not as efficient as it could be.\nIn particular, computing the identifier of a call expression does not leverage\na potentially existing identifier for another call expression in its LHS.","shortMessageHtmlLink":"refactor(compiler-cli): effective narrowing of signal reads in templates"}},{"before":"36f9f37191905e09d8b7a6fcec317acc899ad8cc","after":"9bf3c1a6d6ed46789cc4cc8a2b4ca889679cf060","ref":"refs/heads/core/directive-class-matching","pushedAt":"2024-03-12T15:31:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(core): restructure logic in `isCssClassMatching` function\n\nThe logic in `isCssClassMatching` is only interested in two areas in the attributes:\nimplicit attributes and the `AttributeMarker.Classes` area, with the first area only\nof interest for projection matching, not directive matching. This commit splits these\ntwo searches to make this more apparent.","shortMessageHtmlLink":"refactor(core): restructure logic in <code>isCssClassMatching</code> function"}},{"before":"a7aa0ea5b99eefa80ddc859a987e23447589b63d","after":"36f9f37191905e09d8b7a6fcec317acc899ad8cc","ref":"refs/heads/core/directive-class-matching","pushedAt":"2024-03-12T14:10:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(core): restructure logic in `isCssClassMatching` function\n\nThe logic in `isCssClassMatching` is only interested in two areas in the attributes:\nimplicit attributes and the `AttributeMarker.Classes` area, with the first area only\nof interest for projection matching, not directive matching. This commit splits these\ntwo searches to make this more apparent.","shortMessageHtmlLink":"refactor(core): restructure logic in <code>isCssClassMatching</code> function"}},{"before":"9ab8b490446d17f5e13bed0a6b318e8b9c181622","after":"8c2e98ff757a2367797e8dc13b27a5b3d796f1f8","ref":"refs/heads/signals-ttc","pushedAt":"2024-03-11T17:55:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(compiler-cli): effective narrowing of signal reads in templates\n\nThis commit is an experiment to see how the template type-check block\ncan be modified to support effective narrowing of signal reads.\n\nThe prototype exposes one problem in particular: calling a type guard method\nno longer narrows according to the type-guard, as the method call is indirected\nthough an additional variable.\n\nOther problems with this approach is that diagnostics will not be reported for\nall usages, given that identical call expressions are deduplicated into a single\ncall expression.\n\nThe implementation of this prototype is not as efficient as it could be.\nIn particular, computing the identifier of a call expression does not leverage\na potentially existing identifier for another call expression in its LHS.","shortMessageHtmlLink":"refactor(compiler-cli): effective narrowing of signal reads in templates"}},{"before":"505a6332bee7b4ba5cef5fdd3d3d1c0b9dd33f3f","after":"6f7843c8bf33ac79561eaec15e843a5fde0c69f3","ref":"refs/heads/core/flaky-after-next-render","pushedAt":"2024-03-11T15:45:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(core): avoid additional closure for queued microtask callback\n\nThe `runCallbackOnce` closure is declared not to have any parameters itself, so it is\ncompatible as `queueMicrotask` callback without the extra closure. This reduces the call\nstack by a frame and avoids the extra closure allocation.","shortMessageHtmlLink":"refactor(core): avoid additional closure for queued microtask callback"}},{"before":"0c427a483ce3baaa27880a2f470483d4dcd8a2a6","after":"505a6332bee7b4ba5cef5fdd3d3d1c0b9dd33f3f","ref":"refs/heads/core/flaky-after-next-render","pushedAt":"2024-03-10T21:48:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(core): avoid additional closure for queued microtask callback\n\nThe `runCallbackOnce` closure is declared not to have any parameters itself, so it is\ncompatible as `queueMicrotask` callback without the extra closure. This reduces the call\nstack by a frame and avoids the extra closure allocation.","shortMessageHtmlLink":"refactor(core): avoid additional closure for queued microtask callback"}},{"before":null,"after":"0c427a483ce3baaa27880a2f470483d4dcd8a2a6","ref":"refs/heads/core/flaky-after-next-render","pushedAt":"2024-03-10T21:15:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(core): avoid additional closure for queued microtask callback\n\nThe `runCallbackOnce` closure is declared not to have any parameters itself, so it is\ncompatible as `queueMicrotask` callback without the extra closure. This reduces the call\nstack by a frame and avoids the extra closure allocation.","shortMessageHtmlLink":"refactor(core): avoid additional closure for queued microtask callback"}},{"before":"1c6781ae8d2df783d42a80ba00af87cc09f21e9f","after":"a7aa0ea5b99eefa80ddc859a987e23447589b63d","ref":"refs/heads/core/directive-class-matching","pushedAt":"2024-03-10T21:09:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(core): restructure logic in `isCssClassMatching` function\n\nThe logic in `isCssClassMatching` is only interested in two areas in the attributes:\nimplicit attributes and the `AttributeMarker.Classes` area, with the first area only\nof interest for projection matching, not directive matching. This commit splits these\ntwo searches to make this more apparent.","shortMessageHtmlLink":"refactor(core): restructure logic in <code>isCssClassMatching</code> function"}},{"before":"651582167408b64f9c0496fe1c9e663884ef5531","after":"1c6781ae8d2df783d42a80ba00af87cc09f21e9f","ref":"refs/heads/core/directive-class-matching","pushedAt":"2024-03-10T14:08:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fix(core): exclude class attribute intended for projection matching from directive matching\n\nThis commit resolves a regression that was introduced when the compiler switched from\n`TemplateDefinitionBuilder` (TDB) to the template pipeline (TP) compiler. The TP compiler\nhas changed the output of\n\n```html\nif (false) { <div class=\"test\"></div> }\n```\n\nfrom\n\n```ts\ndefineComponent({\n  consts: [['class', 'test'], [AttributeMarker.Classes, 'test']],\n  template: function(rf) {\n    if (rf & 1) {\n      ɵɵtemplate(0, App_Conditional_0_Template, 2, 0, \"div\", 0)\n    }\n  }\n});\n```\n\nto\n\n```ts\ndefineComponent({\n  consts: [[AttributeMarker.Classes, 'test']],\n  template: function(rf) {\n    if (rf & 1) {\n      ɵɵtemplate(0, App_Conditional_0_Template, 2, 0, \"div\", 0)\n    }\n  }\n});\n```\n\nThe last argument to the `ɵɵtemplate` instruction (0 in both compilation outputs) corresponds with\nthe index in `consts` of the element's attribute's, and we observe how TP has allocated only a single\nattribute array for the `div`, where there used to be two `consts` entries with TDB. Consequently,\nthe `ɵɵtemplate` instruction is now effectively referencing a different attributes array, where the\ndistinction between the `\"class\"` attribute vs. the `AttributeMarker.Classes` distinction affects\nthe behavior: TP's emit causes the runtime to incorrectly match a directive with `selector: '.foo'` to\nbe instantiated on the `ɵɵtemplate` instruction as if it corresponds with a structural directive!\n\nInstead of changing TP to align with TDB's emit, this commit updates the runtime instead. This uncovered\nan inconsistency in selector matching for class names, where there used to be two paths dealing with\nclass matching:\n\n1. The first check was commented to be a special-case for class matching, implemented in `isCssClassMatching`.\n2. The second path was part of the main selector matching algorithm, where `findAttrIndexInNode` was being used\n   to find the start position in `tNode.attrs` to match the selector's value against.\n\nThe second path only considers `AttributeMarker.Classes` values if matching for content projection, OR of the\n`TNode` is not an inline template. The special-case in path 1 however does not make that distinction, so it\nwould consider the `AttributeMarker.Classes` binding as a selector match, incorrectly causing a directive to\nmatch on the `ɵɵtemplate` itself.\n\nThe second path was also buggy for class bindings, as the return value of `classIndexOf` was incorrectly\nnegated: it considered a matching class attribute as non-matching and vice-versa. This bug was not observable\nbecause of another issue, where the class-handling in part 2 was never relevant because of the special-case\nin part 1.\n\nThis commit separates path 1 entirely from path 2 and removes the buggy class-matching logic in part 2, as\nthat is entirely handled by path 1 anyway. `isCssClassMatching` is updated to exclude class bindings from\nbeing matched for inline templates.\n\nFixes #54798","shortMessageHtmlLink":"fix(core): exclude class attribute intended for projection matching f…"}},{"before":null,"after":"651582167408b64f9c0496fe1c9e663884ef5531","ref":"refs/heads/core/directive-class-matching","pushedAt":"2024-03-10T13:40:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fix(core): exclude class attribute intended for projection matching from directive matching\n\nThis commit resolves a regression that was introduced when the compiler switched from\n`TemplateDefinitionBuilder` (TDB) to the template pipeline (TP) compiler. The TP compiler\nhas changed the output of\n\n```html\nif (false) { <div class=\"test\"></div> }\n```\n\nfrom\n\n```ts\ndefineComponent({\n  consts: [['class', 'test'], [AttributeMarker.Classes, 'test']],\n  template: function(rf) {\n    if (rf & 1) {\n      ɵɵtemplate(0, App_Conditional_0_Template, 2, 0, \"div\", 0)\n    }\n  }\n});\n```\n\nto\n\n```ts\ndefineComponent({\n  consts: [[AttributeMarker.Classes, 'test']],\n  template: function(rf) {\n    if (rf & 1) {\n      ɵɵtemplate(0, App_Conditional_0_Template, 2, 0, \"div\", 0)\n    }\n  }\n});\n```\n\nThe last argument to the `ɵɵtemplate` instruction (0 in both compilation outputs) corresponds with\nthe index in `consts` of the element's attribute's, and we observe how TP has allocated only a single\nattribute array for the `div`, where there used to be two `consts` entries with TDB. Consequently,\nthe `ɵɵtemplate` instruction is now effectively referencing a different attributes array, where the\ndistinction between the `\"class\"` attribute vs. the `AttributeMarker.Classes` distinction affects\nthe behavior: TP's emit causes the runtime to incorrectly match a directive with `selector: '.foo'` to\nbe instantiated on the `ɵɵtemplate` instruction as if it corresponds with a structural directive!\n\nInstead of changing TP to align with TDB's emit, this commit updates the runtime instead. This uncovered\nan inconsistency in selector matching for class names, where there used to be two paths dealing with\nclass matching:\n\n1. The first check was commented to be a special-case for class matching, implemented in `isCssClassMatching`.\n2. The second path was part of the main class matching algorithm, where `findAttrIndexInNode` was being used\n   to find the start position in `tNode.attrs` to match the selector's value against.\n\nThe second path only considers `AttributeMarker.Classes` values if matching for content projection, OR of the\n`TNode` is not an inline template. The special-case in 1. however does not make that distinction, so it would\nconsider the `AttributeMarker.Classes` binding as a selector match, incorrectly causing a directive to match\non the `ɵɵtemplate` itself.\n\nThe second path was also buggy for class bindings, as the return value of `classIndexOf` was incorrectly\nnegated: it considered a matching class attribute as non-matching and vice-versa. This bug was not observable\nbecause of another issue, where the class-handling in part 2 was never relevant because of the special-case\nin part 1.\n\nThis commit separates path 1 entirely from path 2 and removes the buggy class-matching logic in part 2, as\nthat is entirely handled by path 1 anyway. `isCssClassMatching` is updated to exclude class bindings from\nbeing matched for inline templates.\n\nFixes #54798","shortMessageHtmlLink":"fix(core): exclude class attribute intended for projection matching f…"}},{"before":"f97e3a1edd498c916771823e995515bf840ff450","after":"da14b1dc9a2e6b3c74592d2086ffbe58789bc743","ref":"refs/heads/compiler/defer-default-import","pushedAt":"2024-02-18T20:07:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fix(compiler-cli): use correct symbol name for default imported symbols in defer blocks\n\nThis commit addresses a problem with PR #53695 that introduced support for default imports,\nwhere the actual dynamic import used in the defer loading function continued to use the\nsymbol name, instead of `.default` for the dynamic import. This issue went unnoticed in the\ntestcase because a proper instance was being generated for the `ɵsetClassMetadataAsync` function,\nbut not the generated dependency loader function.\n\nFixes #54491","shortMessageHtmlLink":"fix(compiler-cli): use correct symbol name for default imported symbo…"}},{"before":null,"after":"f97e3a1edd498c916771823e995515bf840ff450","ref":"refs/heads/compiler/defer-default-import","pushedAt":"2024-02-18T19:48:30.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fix(compiler-cli): use correct symbol name for default imported symbols in defer blocks\n\nThis commit addresses a problem with PR #53695 that introduced support for default imports,\nwhere the actual dynamic import used in the defer loading function continued to use the\nsymbol name, instead of `.default` for the dynamic import. This issue went unnoticed in the\ntestcase because a proper instance was being generated for the `ɵsetClassMetadataAsync` function,\nbut not the generated dependency loader function.\n\nFixes #54491","shortMessageHtmlLink":"fix(compiler-cli): use correct symbol name for default imported symbo…"}},{"before":null,"after":"a6eff00a01a7a5c0a3989b8d43834bf67959beaf","ref":"refs/heads/core/signal-queries-empty","pushedAt":"2024-02-08T20:50:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"fix(core): do not crash for signal query that does not have any matches\n\nThe newly introduced signal queries would error if no match exists, due to an\ninvalid read within the query internals.\n\nThis commit addresses the crash by allowing there to be no matches.","shortMessageHtmlLink":"fix(core): do not crash for signal query that does not have any matches"}},{"before":"6d2327a97aa717cf439ad4d84abdbfe6f55f44e0","after":"c73d3e21107b771b546f7e64a618db58b98a0e84","ref":"refs/heads/compiler/telemetry","pushedAt":"2023-12-27T21:20:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(compiler-cli): include usage count of `async` pipe in telemetry\n\nThis commit extends telemetry data to include the number of 'async' pipe usages.","shortMessageHtmlLink":"refactor(compiler-cli): include usage count of <code>async</code> pipe in telemetry"}},{"before":"9b2dca708be277e3cf77665155805445a7924610","after":"6d2327a97aa717cf439ad4d84abdbfe6f55f44e0","ref":"refs/heads/compiler/telemetry","pushedAt":"2023-12-27T19:27:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"refactor(compiler-cli): include usage count of `async` pipe in telemetry\n\nThis commit extends telemetry data to include the number of 'async' pipe usages.","shortMessageHtmlLink":"refactor(compiler-cli): include usage count of <code>async</code> pipe in telemetry"}},{"before":"a49510fd5caff6a53fe5b06541c4e1ac34a562cd","after":"9b2dca708be277e3cf77665155805445a7924610","ref":"refs/heads/compiler/telemetry","pushedAt":"2023-12-26T11:50:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"test(compiler-cli): add integration tests for telemetry data\n\nThis commit adds tests to verify telemetry data that is gathered during\nanalysis of a compilation unit.","shortMessageHtmlLink":"test(compiler-cli): add integration tests for telemetry data"}},{"before":"9d242e5a88970f118383c04c67ef7322de5c5f45","after":"a49510fd5caff6a53fe5b06541c4e1ac34a562cd","ref":"refs/heads/compiler/telemetry","pushedAt":"2023-12-26T11:45:43.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"JoostK","name":"Joost Koehoorn","path":"/JoostK","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/123679?s=80&v=4"},"commit":{"message":"test(compiler-cli): add integration tests for telemetry data\n\nThis commit adds tests to verify telemetry data that is gathered during\nanalysis of a compilation unit.","shortMessageHtmlLink":"test(compiler-cli): add integration tests for telemetry data"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAENmxxoQA","startCursor":null,"endCursor":null}},"title":"Activity · JoostK/angular"}