show_method_table error #49403
Labels
domain:display and printing
Aesthetics and correctness of printed representations of objects.
kind:regression
Regression in behavior compared to a previous version
Comments
|
Looks like a duplicate if #49382 |
|
Duplicate of #49382 |
|
Hi, I'm learning from this issue. I could not find the reference to |
|
Hi @persinammon! I believe by Taking the julia> ms = methods(Core.OpaqueClosure); # suppress output with ; to avoid the error
julia> ms.ms[1]
Core.OpaqueClosure(ir::Core.Compiler.IRCode, env...; nargs, isva, rt)
@ Base.Experimental opaque_closure.jl:58
julia> (ms.ms[1].module, ms.ms[1].name)
(Base.Experimental, :OpaqueClosure)
julia> isdefined(ms.ms[1].module, ms.ms[1].name)
falseSince |
ararslan
added a commit
that referenced
this issue
Nov 30, 2023
When a type is defined in one module but its methods are defined elsewhere, `show_method_table` errors due to an incorrect lookup of the defining module used to determine colors for printing. In particular, the code had been assuming that the type is defined in the module in which its constructor's first method (in the sense of `first(methods())`) is defined, which isn't always true. To fix this, we can look through the available methods and choose the first in which the type is defined in the method's module, falling back to the method table's module otherwise. Fixes #49382 Fixes #49403 Fixes #52043
ararslan
added a commit
that referenced
this issue
Dec 21, 2023
When a type is defined in one module but its methods are defined elsewhere, `show_method_table` errors due to an incorrect lookup of the defining module used to determine colors for printing. In particular, the code had been assuming that the type is defined in the module in which its constructor's first method (in the sense of `first(methods())`) is defined, which isn't always true. The color used for printing the module name needs to be determined on a per-method basis and can't be correctly done based on the method table's module. For each method, we attempt to derive the module for the method table to which the method was added, then determine whether it's the same as the defining module for the method. Fixes #49382 Fixes #49403 Fixes #52043 Co-Authored-By: Jameson Nash <[email protected]>
ararslan
added a commit
that referenced
this issue
Dec 22, 2023
) When a type is defined in one module but its methods are defined elsewhere, `show_method_table` errors due to an incorrect lookup of the defining module used to determine colors for printing. In particular, the code had been assuming that the type is defined in the module in which its constructor's first method (in the sense of `first(methods())`) is defined, which isn't always true. The color used for printing the module name needs to be determined on a per-method basis and can't be correctly done based on the method table's module. For each method, we attempt to derive the module for the method table to which the method was added, then determine whether it's the same as the defining module for the method. Fixes #49382 Fixes #49403 Fixes #52043 Co-Authored-By: Jameson Nash <[email protected]>
ararslan
added a commit
that referenced
this issue
Dec 22, 2023
) When a type is defined in one module but its methods are defined elsewhere, `show_method_table` errors due to an incorrect lookup of the defining module used to determine colors for printing. In particular, the code had been assuming that the type is defined in the module in which its constructor's first method (in the sense of `first(methods())`) is defined, which isn't always true. The color used for printing the module name needs to be determined on a per-method basis and can't be correctly done based on the method table's module. For each method, we attempt to derive the module for the method table to which the method was added, then determine whether it's the same as the defining module for the method. Fixes #49382 Fixes #49403 Fixes #52043 Co-Authored-By: Jameson Nash <[email protected]> (cherry picked from commit 40bc64c)
KristofferC
pushed a commit
that referenced
this issue
Dec 23, 2023
) When a type is defined in one module but its methods are defined elsewhere, `show_method_table` errors due to an incorrect lookup of the defining module used to determine colors for printing. In particular, the code had been assuming that the type is defined in the module in which its constructor's first method (in the sense of `first(methods())`) is defined, which isn't always true. The color used for printing the module name needs to be determined on a per-method basis and can't be correctly done based on the method table's module. For each method, we attempt to derive the module for the method table to which the method was added, then determine whether it's the same as the defining module for the method. Fixes #49382 Fixes #49403 Fixes #52043 Co-Authored-By: Jameson Nash <[email protected]> (cherry picked from commit 40bc64c)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#45069 seems to assume that
mt[1]value is meaningful (though it seems probably never true), and crashes if is isn'tThe text was updated successfully, but these errors were encountered: