Test for vendor inconsistency and disable vendoring if it is found #308
Conversation
Add taint tracking for bufio and bytes packages
Merge rc/1.25 into master
In a call of the form `f(xs...)`, when we say that `f` taints its 0th argument its ambiguous whether that means that it taints the slice `xs` or its 0th element `xs[0]`. In practice, it's usually the latter, but we have no way of expressing that using our current `FunctionOutput` implementation.
Adds classes for some integer-parsing functions and a constant from strconv, plus a class for calls to integer-parsing functions.
Teach extractor to distinguish calls with an ellipsis from calls without
Merge rc/1.25 into main
Unlike the old ODASA consistency queries, new consistency queries can have expected results, so there is no need to have special handling of files with expected errors.
Enable consistency queries in tests
|
I've added a test for the Go version because Yorck mentioned offhand it might be nice to have support for older Go versions, so I thought I'd give myself a head-start on that in case we decide we do want to support versions < 1.14 in the future. |
|
Looks good, will distcompare and test this with the list of failing projects now |
|
One possible concern: we get |
|
Tested with 94 failing projects from lgtm.com: 79 successfully extracted with this patch. Details on the fails coming up. |
This only applies for module files for which no Go version has been specified; Go will assume these should be parsed with the latest Go version, which will cause them to fail if the vendor directory has been generated with an old version of Go, as the vendor/modules.txt will not meet the new requirements for consistency.
This means dependency installation is still attempted when a vendor directory is inconsistent.
Right. I'd done this because I wanted the builds to happen first, but I hadn't thought about the dependency step. I've moved it to before that by doing it in both of the |
|
Failures are mostly projects with a |
|
Hmm, I assume they also have |
Er, I'll roll that back and put it up in a separate PR. Also, we might want to add a bunch of these edge cases to our extractor tests since this seems like something that's likely to break as the Go team decides what they do and don't like in the future. EDIT: I'll probably do this tomorrow since it's rather... early (?) now. |
|
Sounds good on all fronts :) I'll roll an lgtm.com test-all-project for this PR, probably complete end of tomorrow or so. |
|
Note this is currently based on main but targeting rc/1.25; I'll fix that if and when this passes muster on lgtm.com |
|
I take it this is superseded by #312? If so, let's close this to simplify things. |
This currently depends on #301 because I thought it would be easier to work on top of that than to merge later, though I can split it out if need be.