Track quality of jkinds #3505
Open
Track quality of jkinds #3505
+284
−87
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
glittershark
force-pushed
the
aspsmith/jkind-quality
branch
from
f7e73cf to
4636749
Compare
glittershark
added
typing
modes
glittershark
force-pushed
the
aspsmith/jkind-in-types
branch
from
9fb7e36 to
f2d1d14
Compare
glittershark
force-pushed
the
aspsmith/jkind-quality
branch
from
4636749 to
5c180a9
Compare
glittershark
force-pushed
the
aspsmith/jkind-in-types
branch
from
f2d1d14 to
5e3b03c
Compare
glittershark
force-pushed
the
aspsmith/jkind-quality
branch
2 times, most recently
from
719d602 to
d3b1f27
Compare
Sometimes, inferred jkinds for a type are not exact, but instead *upper bounds*; later, we might learn more about a type that causes us to lower that jkind bound. For example, we might substitute a type variable, or perform `with` substitution on an abstract type in a module type. It's important to know whether this might happen, so that we can avoid normalizing away types with jkinds that might get "better" later from with-bounds during jkind normalization. This commit adds a new "jkind_quality" type, and a "quality" field to jkind, that tracks whether an inferred jkind is "best" or "not best", and sets this to the correct value everywhere jkinds are constructed. Nothing actually /reads/ this field yet, but this will be used during normalization in a subsequent commit.
glittershark
force-pushed
the
aspsmith/jkind-quality
branch
from
d3b1f27 to
523ec09
Compare
goldfirere
reviewed
Jan 29, 2025
|
Reviewed two commits ("add some extra comments from review".."more comments, specifically documenting quality"). They look good to me. |
we don't want to mark stuff as best too early, here; instead we want to wait until we've added all the necessary bounds (such that we /actually/ have a best kind!)
goldfirere
approved these changes
Jan 31, 2025
it's weird, and we don't need it, so let's just remove it
goldfirere
reviewed
Feb 3, 2025
|
Reviewed latest commits. This one looks good |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Sometimes, inferred jkinds for a type are not exact, but instead upper bounds;
later, we might learn more about a type that causes us to lower that jkind
bound. For example, we might substitute a type variable, or perform
withsubstitution on an abstract type in a module type. It's important to know
whether this might happen, so that we can avoid normalizing away types with
jkinds that might get "better" later from with-bounds during jkind
normalization.
This commit adds a new "jkind_quality" type, and a "quality" field to jkind,
that tracks whether an inferred jkind is "best" or "not best", and sets this to
the correct value everywhere jkinds are constructed. Nothing actually /reads/
this field yet, but this will be used during normalization in a subsequent
commit.