`definition(String, m)` returns `nothing` for a closure when the enclosing function has arguments

Ouverte
#162 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
75/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
julia
Domaine
devtools

Piste de recherche

Start in src/utils.jl at is_func_expr(ex, meth::Method), then run repro.jl with include on the stated Julia and CodeTracking versions to reproduce the parameterized-closure failures. Trace the backward scan, gensym name matching, and argument comparison. Done means definition(String, m) finds the source for all arrow and do-block closures, including those inside functions with parameters.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

definition(String, m) for a closure's method (a do block or a -> inside a call) returns nothing whenever the function it is written inside has parameters. With no parameters it works. The distinction is the enclosing function's argument list, not the closure form or whether the enclosing function is short- or long-form.

Repro (repro.jl, run with include; Julia 1.13.0, CodeTracking 3.0.2, no Revise needed):

using CodeTracking
returnit(f) = f
# short form, enclosing has no args / has args; arrow / do
s_noargs_arrow()  = returnit(y -> y + 1)
s_args_arrow(x)   = returnit(y -> y + x)
s_noargs_do()     = returnit() do y
    y + 1
end
s_args_do(x)      = returnit() do y
    y + x
end
# long form
function l_noargs_arrow()
    return returnit(y -> y + 1)
end
function l_args_arrow(x)
    return returnit(y -> y + x)
end
function l_noargs_do()
    return returnit() do y
        y + 1
    end
end
function l_args_do(x)
    return returnit() do y
        y + x
    end
end
for (make, args) in ((s_noargs_arrow, ()), (s_args_arrow, (1,)), (s_noargs_do, ()), (s_args_do, (1,)),
                     (l_noargs_arrow, ()), (l_args_arrow, (1,)), (l_noargs_do, ()), (l_args_do, (1,)))
    m = only(methods(make(args...)))
    d = CodeTracking.definition(String, m)
    println(rpad(string(make), 16), " closure at line ", lpad(m.line, 2), "  -> ", d === nothing ? "nothing" : "found (starts at line $(d[2]))")
end

Output:

s_noargs_arrow   closure at line  4  -> found (starts at line 4)
s_args_arrow     closure at line  5  -> nothing
s_noargs_do      closure at line  7  -> found (starts at line 5)
s_args_do        closure at line 10  -> nothing
l_noargs_arrow   closure at line 14  -> found (starts at line 12)
l_args_arrow     closure at line 17  -> nothing
l_noargs_do      closure at line 21  -> found (starts at line 18)
l_args_do        closure at line 26  -> nothing

Where it happens — is_func_expr(ex, meth::Method) in src/utils.jl:

  • The backward scan from the closure's line reaches the enclosing definition, and the name check accepts it on purpose: fname === strip_gensym(meth.name) maps #l_args_do##0 to l_args_do. So far so good — the enclosing definition is the text that contains the closure.
  • It then "matches the argnames": exargs are the enclosing definition's parameters (x), zipped against Base.method_argnames(meth)[2:end], which are the closure's (y). x !== y → return false. When the enclosing function has no parameters the zip is empty and the check passes, which is why the noargs rows succeed.

So for a gensym-named method the argument check is comparing two different functions' parameter lists. A closure whose parameter names happen to coincide positionally with the enclosing function's would pass by accident.

Suggested fix: when meth.name is a gensym and the expression matched via strip_gensym, skip the argname comparison (the enclosing definition is the right answer, and the caller has meth.line to find the lambda inside it), or locate the ->/do node within ex and compare its parameters instead.

Downstream effect: TypedSyntax calls definition(String, m) first, so Cthulhu's source view cannot show any closure written inside a function with parameters — e.g. stable_hash_helper(x::Tuple, hash_state, context, ::StructTypes.ArrayType) in StableHashTraits, whose do nested_hash_state block reports couldn't retrieve source of (::var"#stable_hash_helper##4#…")(nested_hash_state). Related earlier reports: #102 (added -> matching), #132 (closed; a lambda returned as data, which is a different case — here the file and line are known and correct).


🤖 Filed using Claude Code. The reproduction was run locally on the stated versions and the output is quoted verbatim.

Langage dominant
Julia
Étoiles
150
Forks
12
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de JuliaDebug/CodeTracking.jl

Toutes les issues de JuliaDebug/CodeTracking.jl

Issues similaires

Plus d'issues Julia

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.