show: user-facing display of Core.TypeEgal arguments in errors and call signatures - #22
Open
adienes wants to merge 3 commits into
Open
show: user-facing display of Core.TypeEgal arguments in errors and call signatures#22adienes wants to merge 3 commits into
Core.TypeEgal arguments in errors and call signatures#22adienes wants to merge 3 commits into
Conversation
When a method candidate has a trailing vararg beyond the supplied arguments, it is satisfiable by zero arguments and is deliberately not highlighted as a mismatch. This branch predates JuliaLang#61651, which moved matching parameters and separators from the default color to gray, so the bare vararg was left as the only default-colored parameter in an otherwise gray/red candidate signature. Print it in gray like any other matching parameter. The no-color output is unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Since JuliaLang#62001, Core.Typeof of a closed type-valued argument is the egality kind Core.TypeEgal{X}, which leaked its canonical spelling into every rendered call signature: MethodError headers ("no method matching sqrt(::Core.TypeEgal{Int64})"), convert errors, ambiguity errors, stack-trace frames, and MethodInstance display, while method candidates and definitions continue to show the Type{X} spelling. Call display is prescriptive: users copy the printed signature into a method definition, and the method they should write is the idiomatic zero(::Type{Int64}), which accepts the TypeEgal argument, not a method on the internal kind. Map TypeEgal{X} to Type{X} in show_tuple_as_call and show_convert_error, mirroring the identification descend_params already makes when highlighting candidate mismatches. Reflection (typesof), repr, and type-space display remain exact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Where the egality kind is displayed as a type (repr, container element
types, methods dispatching on the kind, compiler output), the canonical
Core.TypeEgal{X} spelling is unfamiliar and gives no hint how to obtain
such a type. Print it compactly as Core.Typeof(X), which round-trips
(Core.Typeof(X) === Core.TypeEgal{X} for any closed X) analogously to
the typeof(sin) spelling of function singleton types. Non-compact
printing keeps the canonical kind name, and the REPL text/plain display
shows both, as Core.Typeof(Int64) (alias for Core.TypeEgal{Int64}),
mirroring the existing Type{Int64} (alias for TypeEq{Int64}) display of
the equality kind.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Since JuliaLang#62001 introduced the egality kind,
Core.Typeofof a closed type-valued argument isCore.TypeEgal{X}, and its canonical spelling leaks into every rendered call: MethodError headers now readno method matching sqrt(::Core.TypeEgal{Int64}), and the same appears in convert errors, ambiguity errors, stack-trace frames, andMethodInstancedisplay — while method candidates and definitions continue to print the familiarType{X}spelling.This PR settles the display along a prescriptive/descriptive line:
::Type{X}. A printed call signature is what users copy into a method definition, and the method they should write is the idiomaticzero(::Type{Int64})(which accepts theTypeEgalargument), not a method on the internal kind. The mapping lives inshow_tuple_as_call(covering MethodError/ambiguity headers, backtrace frames, andMethodInstancedisplay, sincespecTypesgenuinely carryTypeEgal) andshow_convert_error, mirroring the identificationdescend_paramsalready makes when highlighting candidate mismatches (errorshow: highlight nested type mismatches in MethodError candidates JuliaLang/julia#61651). Reflection (typesof) is untouched.Core.Typeof(X). Where the kind legitimately appears as a type (repr, container element types, methods defined on the kind, compiler output),Core.TypeEgal{X}gives no hint how to obtain such a type.Core.Typeof(X)round-trips exactly (Core.Typeof(X) === Core.TypeEgal{X}for closedX), analogous to thetypeof(sin)spelling of function singleton types. The REPL showsCore.Typeof(Int64) (alias for Core.TypeEgal{Int64}), mirroring the existingType{Int64} (alias for TypeEq{Int64}).Any...inzero(::Type{Union{}}, Any...).Known seam: a method explicitly defined on the kind shows
h(::Core.Typeof(Int64))in candidates while a failing call's header prints the call-position::Type{Int8}spelling; this corner faces kinds-aware users and seems acceptable.The
errorshow,ambiguous, andshowtest suites pass, and the manual's doctests are updated (methods.md's stalejulia-replblock modernized alongside).This pull request was written with the assistance of generative AI (Claude).
🤖 Generated with Claude Code