fix getType on object/distinct types giving bare generic sym #24510
+4
−6
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.
fixes #24503, refs #22655, alternative to #24509
This removes the need for the fix in #22655 entirely, since
getTypeno longer gives nodes with invalidtyGenericBodytypes for types that are actually instantiated. But it significantly changes the output ofgetType, and likely not in a great way. Maybe aninst=trueversion oft.typeInstwould be better, but this also changes the output, andt.typeInstwas only fixed recently for types without generic fields in #24425 (also the dereferenced types of genericref objects still give theref objecttype as thetypeInst).There is also this line that has a similar issue, but it doesn't seem to be encountered, likely because skipped
tyGenericInsttypes aren't very common when usinggetTypeInst.Alternatively we could still produce a sym node but just set its type to the current type, i.e.
result = atomicType(t.sym); result.typ = t. Edit: Done in #24511 just to test