fix(compiler-cli): more accurate diagnostics for host binding parser errors#58870
fix(compiler-cli): more accurate diagnostics for host binding parser errors#58870crisbeto wants to merge 1 commit intoangular:mainfrom
Conversation
JoostK
left a comment
There was a problem hiding this comment.
One additional gotcha here could be for duplicate host binding expressions; they would report individual errors for each occurrence, but will then all get reported on the first host binding occurrence.
Overall this still seems like an improvement 👍
|
I was thinking about duplicates as well, but I don't think they'll be a problem because we throw a |
…errors Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a `Record<string, string>` since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE. These changes aim to report a more accurate error for the most common case where the `host` object is initialized to a `string -> string` object literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases like `host: SOME_CONST`, but it's still better than the current setup.
8abee16 to
119877b
Compare
…errors (#58870) Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a `Record<string, string>` since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE. These changes aim to report a more accurate error for the most common case where the `host` object is initialized to a `string -> string` object literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases like `host: SOME_CONST`, but it's still better than the current setup. PR Close #58870
|
This PR was merged into the repository by commit 4e92449. The changes were merged into the following branches: main, 19.0.x |
|
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. |
Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a
Record<string, string>since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE.These changes aim to report a more accurate error for the most common case where the
hostobject is initialized to astring -> stringobject literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases likehost: SOME_CONST, but it's still better than the current setup.Before:

After:
