Go: Check more things while running tests#19491
Conversation
|
The CI has highlighted a db inconsistency that only happens on windows: the container parent of "C:/a" is recorded as both "C:/" and "C:". This only happens in tests with html files, hence it must be related to the xml extractor. |
c42710a to
afc4bf3
Compare
There was a problem hiding this comment.
Pull Request Overview
Adds more validation flags to the CodeQL test command and refactors the Go extractor’s path handling and nil checks.
- Introduces
rawPath/canonicalPathinextractFileInfoto normalize file paths. - Simplifies nil checks in
extractExpr,extractStmt, andextractDeclby moving them to the top. - Updates test runner flags in
Makefileand adjusts GitHub Actions Windows runner configuration. - Aligns
greet.goimport alias with updated definitions expected output.
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| go/ql/test/query-tests/definitions/greet.go | Renamed import to myfmt and updated print call |
| go/ql/test/query-tests/definitions/definitions.expected | Added new definition entry for myfmt |
| go/extractor/extractor.go | Introduced rawPath/canonicalPath, refactored nil checks |
| go/Makefile | Added new --check-* flags to codeql test run |
| .github/workflows/go-tests-other-os.yml | Changed runs-on from windows-latest-xl to windows-latest |
Comments suppressed due to low confidence (1)
go/Makefile:57
- Remove the
--check-unused-labelsflag, as noted in the PR description, to prevent unintended test failures caused by trap errors and ensure consistency with the intended test configuration.
codeql test run -j0 ql/test --search-path .. --consistency-queries ql/test/consistency --compilation-cache=$(cache) --dynamic-join-order-mode=$(rtjo) --check-databases --fail-on-trap-errors --check-undefined-labels --check-unused-labels --check-repeated-labels --check-redefined-labels --check-use-before-definition
| if path != "/" { | ||
| parentPath = path | ||
| } | ||
| parentPath = rawPath |
There was a problem hiding this comment.
Unconditionally assigning parentPath = rawPath will make the next iteration build rawPath differently when rawPath is empty (root). Consider guarding this assignment for root paths (e.g. only set parentPath when rawPath is non-empty) to preserve correct canonical paths.
| parentPath = rawPath | |
| if rawPath != "" { | |
| parentPath = rawPath | |
| } |
This makes the test slightly more thorough.
In go, an interface with value nil does not compare equal to nil. This is known as "typed nils". So our existing nil checks weren't working, which shows why we needed more nil checks inside the type switches. The solution is to explicitly check for each type we care about.
85d5922 to
83cd349
Compare
smowton
left a comment
There was a problem hiding this comment.
Path-formatting and test flag changes LGTM. Suggest not making the nil-check changes.
| // extractExpr extracts AST information for the given expression and all its subexpressions | ||
| func extractExpr(tw *trap.Writer, expr ast.Expr, parent trap.Label, idx int, skipExtractingValue bool) { | ||
| if expr == nil { | ||
| if expr == nil || expr == (*ast.Ident)(nil) || expr == (*ast.BasicLit)(nil) || |
There was a problem hiding this comment.
TIL: this makes sense. It does, though! Weak preference for keeping the old code, since as/when there are new AST nodes it is now easier to accidentally not add the nil check.
There was a problem hiding this comment.
as a Go neophyte, after doing a quick google search, would something like expr == nil || reflect.ValueOf(i).IsNil() work and avoid the problem?
There was a problem hiding this comment.
It's a definite footgun in the language, which I think they probably should have a better solution for. Btw there is an alternative which I saw suggested when I searched for this online, which is to use reflection to check if the interface type has a nil value. I thought this was too ugly, but it would address the concern that we need to remember to add any new types to the check.
You want to leave in the nil checks in the branches of the type switch? I don't really agree, but I'll do it as it isn't worth debating.
There was a problem hiding this comment.
My comment above was a response to @smowton 's comment. I'm not sure about the exact formulation of using reflection. Since we know it will be an interface and not a map or channel or anything like that, it shouldn't be too hard.
There was a problem hiding this comment.
If the reflection isn't too costly that's fine. After that I'd say a check in each branch is slightly better the a mass of checks up front, because the up-front ones can drift out of sync with the arms of the switch too easily.
There was a problem hiding this comment.
It's a definite footgun in the language
So true! TIL, I'll definitely keep that in mind for next time I might dabble with Go.
There was a problem hiding this comment.
Another idea occurred to me: we just move the two lines that are above the type switch into every case clause. Then the nil check works as expected. There is duplication, but it isn't too bad, and anyone adding another case in future will be able to copy from other case clauses without any risk of error. I think if reflection works and is performant then that is probably my first choice, followed by this duplication approach.
| // extractExpr extracts AST information for the given expression and all its subexpressions | ||
| func extractExpr(tw *trap.Writer, expr ast.Expr, parent trap.Label, idx int, skipExtractingValue bool) { | ||
| if expr == nil { | ||
| if expr == nil || expr == (*ast.Ident)(nil) || expr == (*ast.BasicLit)(nil) || |
There was a problem hiding this comment.
as a Go neophyte, after doing a quick google search, would something like expr == nil || reflect.ValueOf(i).IsNil() work and avoid the problem?
|
I have switched to using reflection for the nil check on interfaces. DCA showed no significant changes in build time - on the two largest repos it reduces it, if anything. I will do a QA run to be sure. |
|
QA showed no negative consequences. The build step was took on average 1.68% less time and the analysis step took on average 1% less time. It's tempting to think that this PR caused that, but it may well just be noise. There was one alert difference - I'll double check it locally. |
|
I wasn't able to reproduce the alert difference locally. My best guess was that the repo was updated between the left run and the right run, but actually it hasn't been updated for two years. |
This PR adds the following flags when we run tests:
--fail-on-trap-errors,--check-undefined-labels,--check-unused-labels,--check-repeated-labels,--check-redefined-labels,--check-use-before-definition. There are also two extractor fixes to make tests pass with these flags: