internals: add _defaultctor function for defining ctors #57317
Conversation
Deferring this part of defining the ctor code allows it to do some
value-based optimizations, without the awkwardness previously of needing
to do conditional lowering of all of the possible versions that might be
useful just from syntax transforms. This feels very like a generated
function: how it expands just the function body, except it is flipped so
that then we wrap the result in a single Method instead of being created
from a Method!
Avoids lowering inaccuracies where a variable appears but is not used.
These warnings are now prevented:
```julia
julia> struct Foo{T}
x::(T; Any)
end
WARNING: method definition for Foo at REPL[1]:2 declares type variable T but does not use it.
julia> struct Foo{T}
x::Union{Any, T}
end
WARNING: method definition for Foo at REPL[1]:2 declares type variable T but does not use it.
```
Avoids hitting #31542.
This lowering mistake is now avoided:
```julia
julia> struct Foo{T}
x::(Val{T} where T)
end
ERROR: syntax: invalid variable expression in "where" around REPL[1]:2
```
As a minor optimization, this avoids generating a `convert` call when
the user declares explicit `::Any` declarations, the same as if the user
didn't annotate the field type:
```julia
julia> struct Foo
x::Any
y::Int
z
end
julia> code_lowered(Foo)[2]
CodeInfo(
@ REPL[1]:2 within `unknown scope`
1 ─ %1 = builtin Core.fieldtype(#ctor-self#, 2)
│ %2 = y
│ @_4 = %2
│ %4 = builtin @_4 isa %1
└── goto #3 if not %4
2 ─ goto #4
3 ─ @_4 = Base.convert(%1, @_4)
4 ┄ %8 = @_4
│ %9 = %new(#ctor-self#, x, %8, z)
└── return %9
)
```
vtjnash
added
compiler:lowering
|
Does JuliaLowering need to copy this? |
|
Is there any strong reason to write this code in C? I have been generally hoping to move more of this kind of code to Julia. |
|
Bootstrapping mainly--ctors are pretty low level and important. In theory this should be replaceable by any arbitrary call later, although Revise may want to model it |
|
It may be an interesting use case for binding replacement too, as we could turn this into a julia function after bootstrapping gets far enough |
|
I guess my question was mainly, which default ctors do we define between the point where bootstrapping is far enough that struct definition works at all and the point where we have enough infrastructure to write this function. My intuition would be that that delta isn't actually that large, but I don't know. |
Deferring this part of defining the ctor code allows it to do some value-based optimizations, without the awkwardness previously of needing to do conditional lowering of all of the possible versions that might be useful just from syntax transforms. This feels very like a generated function: how it expands just the function body, except it is flipped so that then we wrap the result in a single Method instead of being created from a Method!
Avoids lowering inaccuracies where a variable appears but is not used. These warnings are now prevented:
Avoids hitting #31542. This lowering mistake is now avoided:
As a minor optimization, this avoids generating a
convertcall when the user declares explicit::Anydeclarations, the same as if the user didn't annotate the field type:The outer/inner names might be a bit historical at this point (predating where clauses allowing specifying them flexibly inside or outside of the struct def): they are really exact-type-type&convert-args-from-any / exact-arg-types&apply-type-from-args if named for precisely what they do.