fix(template-parser): visit receiver of Call expression #1887
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit d26bbcb. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 7 targetsSent with 💌 from NxCloud. |
|
Hi, any info on this? I've updated the PR after |
|
I've rebased the changes on top of the most recent |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1887 +/- ##
=======================================
Coverage 91.73% 91.73%
=======================================
Files 181 181
Lines 3401 3401
Branches 552 552
=======================================
Hits 3120 3120
Misses 144 144
Partials 137 137
Flags with carried forward coverage won't be shown. Click here to find out more.
|
| ]; | ||
|
|
||
| // convertAnnotatedSourceToFailureCase unfortunately cannot handle multiple errors starting/ending at the same position; |
There was a problem hiding this comment.
It's our own utility, so feels a little weird to add a comment saying "unfortunately cannot handle". Can we make it handle it? 🤔
There was a problem hiding this comment.
I looked at the implementation, but only briefly, I didn't really want this PR to turn into a side-quest of re-writing a test utility to handle just these few cases.
If you feel that it's worthwhile, I can try and implement the necessary changes.
There was a problem hiding this comment.
It's a unit test utility right, so a super fast feedback loop - if the existing tests and the new tests pass then the patch is "correct" :)
If it bogs you down for a long time then let me know, but it's definitely worth giving it a go
There was a problem hiding this comment.
Alright, I think I've managed to finally figure it out - this hack is no longer necessary and the other tests didn't break.
The code for processing annotated cases assumed the code would always be at line-1, but this is not true if we have multiple lines of annotations, I changed it to instead keep track of the last non-annotation line and use that for setting start and end line positions
When traversing a Call AST node, ESLint would never visit its receiver/callee. Since Call didn't have visitor keys listed explicitly, the parser would use `getFallbackKeys`, which seems to be buggy as it only returns `args` and not `receiver`. Update test cases for no-call-expression to deal with new call expressions being reported. Since convertAnnotatedSourceToFailureCase doesn't deal well with overlapping errors at the moment, instances of `()()` were removed from existing tests and added as separate cases for nested calls. Closes angular-eslint#1885
follow-up to 4292d10, fixes an identical problem with calls like `foo?.()` which are represented as a separate node type.
…line rewrite the parseInvalidSource to keep track of last non-annotation line instead of assuming it's always the previous line. enables writing test cases with multiple errors starting/ending at the same position in code
This reverts commit 709a2c4.
|
@P4 I'm afraid I'm not sure what happened with this one, but the tests are not passing, so I have reverted it on |
When traversing a Call AST node, ESLint would never visit its receiver/callee. Since Call didn't have visitor keys listed explicitly, the parser would use
getFallbackKeys, which seems to be buggy as it only returnsargsand notreceiver.Update test cases for no-call-expression to deal with new call expressions being reported.
Since convertAnnotatedSourceToFailureCase doesn't deal well with overlapping errors at the moment, instances of
()()were removed from existing tests and added as separate cases for nested calls.Closes #1885