-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add a lowered representation for markers #9341
Conversation
c00c975
to
d3a9b27
Compare
This does mean that we'll "drop" invalid extras, like |
.name() | ||
.as_extra() | ||
.is_some_and(|extra| extras.contains(extra)), | ||
) |
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.
Just an example of the simplification that we get in return. This specific case is obviously not a big win, but changing the representation (such that we have an internal representation that's separate from the exact grammar and how they're parsed) is the crucial piece.
55a569d
to
5eca3e9
Compare
d3a9b27
to
6d6b863
Compare
## Summary This PR introduces a set of parallel structs to `MarkerValueString`, `MarkerValueExtra`, and `MarkerValueVersion` that remove various pieces of information and representations that shouldn't be available in the marker algebra. To start, I've _just_ removed the invalid extra component from `MarkerValueExtra` -- there are no other changes to the representation. So, throughout the marker algebra, we can't represent and thus don't have to worry about clauses with invalid extras. The subsequent changes I plan to make are: 1. Removing `python_version`, since we exclusively use `python_version_full` in the algebra. 2. Removing the deprecated aliases, such that we re-map to the correct marker value. 3. Consolidating `sys_platform` and `platform_release` (the original motivation).
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.
nit: Maybe ParsedMarker<...>
vs CanonicalMarlker<...>
?
Code looks good
## Summary This PR introduces a set of parallel structs to `MarkerValueString`, `MarkerValueExtra`, and `MarkerValueVersion` that remove various pieces of information and representations that shouldn't be available in the marker algebra. To start, I've _just_ removed the invalid extra component from `MarkerValueExtra` -- there are no other changes to the representation. So, throughout the marker algebra, we can't represent and thus don't have to worry about clauses with invalid extras. The subsequent changes I plan to make are: 1. Removing `python_version`, since we exclusively use `python_version_full` in the algebra. 2. Removing the deprecated aliases, such that we re-map to the correct marker value. 3. Consolidating `sys_platform` and `platform_release` (the original motivation).
By request: #9341 (review).
Summary
This PR introduces a set of parallel structs to
MarkerValueString
,MarkerValueExtra
, andMarkerValueVersion
that remove various pieces of information and representations that shouldn't be available in the marker algebra. To start, I've just removed the invalid extra component fromMarkerValueExtra
-- there are no other changes to the representation. So, throughout the marker algebra, we can't represent and thus don't have to worry about clauses with invalid extras.The subsequent changes I plan to make are:
python_version
, since we exclusively usepython_version_full
in the algebra.sys_platform
andplatform_release
(the original motivation).