Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Go: Make version parsing robust in the face of custom Go builds #21817
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Go: Make version parsing robust in the face of custom Go builds #21817
Changes from all commits
e38303bFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about this approach. It probably solves the immediate issue, but why not use the existing machinery we have in
semver.go? I.e. wrap this inSemVerusingNewSemVer. That will parse the semver (and should account for some Go special cases). You can then extract only the components you care about (to ignore the prerelease identifier and e.g. the build info if we don't care about those).That said, we might want to think about the semver ordering rules and how we should treat prerelease identifiers or build info, rather than just discarding it.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how you can make your first proposal work without creating code that flat out conflicts with the current
-rchandling. Specificallycodeql/go/extractor/util/semver.go
Line 84 in 8cc6d78
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That part of the implementation is hacky for sure and probably breaks some theoretical inputs in any case, but my reading of it is that:
rcanywhere, then it is treated as a semver in the normal way. I.e. the pre-release identifier is kept as is. This should cover most of the potential cases we discussed in the thread.rcsomewhere, then this logic kicks in to try and convert it to-rc[..].If we think that the potential breakage in the
rccase is a problem, then we should probably address that in theNewSemVerimplementation since the same version strings are likely to end up in there at some point as well.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. It's not clear what we gain by all this though, without yet another major rewrite. Assuming Copilot above is correct, then the case we will be missing here is
go version devel go1.22-abc123def456 linux/amd64, but we don't handle that anyway, as we have hardcodedstrings.Fields(lastLine)[2].Uh oh!
There was an error while loading. Please reload this page.