java inline expectations proof-of-concept with tests #16911
Conversation
dc5f876
to
6c957f9
Compare
6c957f9
to
65655db
Compare
| s = actualLines() and | ||
| posString = s.substring(s.indexOf("|", 0, 0) + 1, s.indexOf("|", 1, 0)).trim() and | ||
| filename = posString.substring(0, posString.indexOf(":", 0, 0)) and | ||
| lineString = posString.substring(posString.indexOf(":", 0, 0) + 1, posString.indexOf(":", 1, 0)) and | ||
| lineString = posString.substring(posString.indexOf(":", 2, 0) + 1, posString.indexOf(":", 3, 0)) and | ||
| colStart = | ||
| posString.substring(posString.indexOf(":", 1, 0) + 1, posString.indexOf(":", 2, 0)).toInt() and | ||
| colEnd = posString.substring(posString.indexOf(":", 3, 0) + 1, posString.length()).toInt() and | ||
| line = lineString.toInt() and | ||
| content = s.substring(s.indexOf("|", 2, 0) + 1, s.indexOf("|", 3, 0)).trim() |
There was a problem hiding this comment.
Is this meant as an example of best practice? If not, I'd like to see such an example. That will help us confirm we have the right interface.
There was a problem hiding this comment.
Do you mean whether my proof-of-concept inline expectations query is meant as best practice? I certainly wouldn't claim so, I just tried to have something that works well enough to verify the CLI part.
There is a test case below that gives an example of this code working in practice:
Perhaps I misunderstand what you mean, though?
There was a problem hiding this comment.
What I mean is that the QL code works by concatenating all the columns and then splitting by | to take them apart again. I hope that's unnecessary.
There was a problem hiding this comment.
Apologies, I see what you mean now.
This concatenation is completely unnecessary and merely an artifact of me having gone through multiple different interfaces while working on this issue and not properly cleaning up the QL code after the most recent change.
I have pushed a third commit to remove actualLines and with it the concatenation.
abf9a0a
to
402f835
Compare
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations1.ql
Dismissed
Show dismissed
Hide dismissed
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations2.ql
Dismissed
Show dismissed
Hide dismissed
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations3.ql
Dismissed
Show dismissed
Hide dismissed
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations1.ql
Dismissed
Show dismissed
Hide dismissed
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations2.ql
Dismissed
Show dismissed
Hide dismissed
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations3.ql
Dismissed
Show dismissed
Hide dismissed
java/ql/test/TestUtilities/ProblematicJavaInlineExpectations4.ql
Dismissed
Show dismissed
Hide dismissed
402f835
to
7370a2e
Compare
7078c40
to
c86e008
Compare
This is a proof-of-concept inline expectations query that I developed alongside the CLI implementation of test postprocessing to verify that everything works and the interface makes sense. It is not meant to be merged, but should serve as inspiration for a proper version.
Note that
java/ql/test/query-tests/Postprocessing/passing/SuspiciousRegexpRange.javais an identical copy ofjava/ql/test/query-tests/security/CWE-020/SuspiciousRegexpRange.java, with the other added (non-empty) .java files being slight variations.