From 18be7a75ebc9f9116c413d06f8c97dd93c31dfcf Mon Sep 17 00:00:00 2001 From: Florian Atteneder Date: Sun, 3 Nov 2024 10:31:16 +0100 Subject: [PATCH] replace more 'leaf type' occurences with 'concrete type' Co-authored-by: inkydragon --- base/reflection.jl | 4 ++-- base/runtime_internals.jl | 4 ++-- stdlib/InteractiveUtils/src/codeview.jl | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/base/reflection.jl b/base/reflection.jl index f2a554e0f27c5b..0b7612e44f7448 100644 --- a/base/reflection.jl +++ b/base/reflection.jl @@ -15,7 +15,7 @@ yielded by expanding the generators. The keyword `debuginfo` controls the amount of code metadata present in the output. -Note that an error will be thrown if `types` are not leaf types when `generated` is +Note that an error will be thrown if `types` are not concrete types when `generated` is `true` and any of the corresponding methods are an `@generated` method. """ function code_lowered(@nospecialize(f), @nospecialize(t=Tuple); generated::Bool=true, debuginfo::Symbol=:default) @@ -37,7 +37,7 @@ function code_lowered(@nospecialize(f), @nospecialize(t=Tuple); generated::Bool= else error("Could not expand generator for `@generated` method ", m, ". ", "This can happen if the provided argument types (", t, ") are ", - "not leaf types, but the `generated` argument is `true`.") + "not concrete types, but the `generated` argument is `true`.") end else code = uncompressed_ir(m.def::Method) diff --git a/base/runtime_internals.jl b/base/runtime_internals.jl index 1da58af38d545b..4a04d406550b73 100644 --- a/base/runtime_internals.jl +++ b/base/runtime_internals.jl @@ -839,7 +839,7 @@ end """ isdispatchtuple(T) -Determine whether type `T` is a tuple "leaf type", +Determine whether type `T` is a tuple of concrete types, meaning it could appear as a type signature in dispatch and has no subtypes (or supertypes) which could appear in a call. If `T` is not a type, then return `false`. @@ -894,7 +894,7 @@ isconcretedispatch(@nospecialize t) = isconcretetype(t) && !iskindtype(t) using Core: has_free_typevars # equivalent to isa(v, Type) && isdispatchtuple(Tuple{v}) || v === Union{} -# and is thus perhaps most similar to the old (pre-1.0) `isleaftype` query +# and is thus perhaps most similar to the old (pre-1.0) `isconcretetype` query function isdispatchelem(@nospecialize v) return (v === Bottom) || (v === typeof(Bottom)) || isconcretedispatch(v) || (isType(v) && !has_free_typevars(v)) diff --git a/stdlib/InteractiveUtils/src/codeview.jl b/stdlib/InteractiveUtils/src/codeview.jl index e3ef0a14a6608f..92354d2fb9a755 100644 --- a/stdlib/InteractiveUtils/src/codeview.jl +++ b/stdlib/InteractiveUtils/src/codeview.jl @@ -128,10 +128,10 @@ end Prints lowered and type-inferred ASTs for the methods matching the given generic function and type signature to `io` which defaults to `stdout`. The ASTs are annotated in such a way -as to cause "non-leaf" types which may be problematic for performance to be emphasized +as to cause non-concrete types which may be problematic for performance to be emphasized (if color is available, displayed in red). This serves as a warning of potential type instability. -Not all non-leaf types are particularly problematic for performance, and the performance +Not all non-concrete types are particularly problematic for performance, and the performance characteristics of a particular type is an implementation detail of the compiler. `code_warntype` will err on the side of coloring types red if they might be a performance concern, so some types may be colored red even if they do not impact performance.