You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is an actual bug or we are doing something weird, but I've found that if we have a BUILD file with a target which is a macro that returns a value (such as a struct, with the names of a few internally instantiated targets), then a command like buildozer 'print label srcs' //foo will print an error that the rule cannot be found, even if buildozer 'print label srcs' //foo:* shows that the rule exists.
but if the macro is made to return something, and that value is assigned to a variable in the BUILD.bazel file, then buildozer can no longer find the rule/target:
// "%<LINENUM>" will match the rule which begins at LINENUM.
// This is for convenience, "%" is not a valid character in bazel targets.
ifresult, err:=strconv.Atoi(name[1:]); err==nil {
linenum=result
}
}
fori, stmt:=rangef.Stmt {
call, ok:=stmt.(*build.CallExpr)
if!ok {
continue
}
r:=f.Rule(call)
start, _:=call.X.Span()
ifr.Name() ==name||start.Line==linenum {
returni, r
}
// Allow for precisely targeting the package declaration. This
// helps adding new load() and license() rules
ifname=="__pkg__" {
ifrule, ok:=ExprToRule(stmt, "package"); ok {
returni, rule
}
}
}
return-1, nil
}
only examines nodes in the BUILD file AST which are CallExpr, and assigning the return value of a macro (which I can't tell is an unorthodox thing to do?) changes that node to an AssignExpr.
The text was updated successfully, but these errors were encountered:
I'm not sure if this is an actual bug or we are doing something weird, but I've found that if we have a BUILD file with a target which is a macro that returns a value (such as a struct, with the names of a few internally instantiated targets), then a command like
buildozer 'print label srcs' //foo
will print an error that the rule cannot be found, even ifbuildozer 'print label srcs' //foo:*
shows that the rule exists.I created a repo which reproduces the issue: https://github.com/mattnworb/buildozer-macro-return-issue
For instance, in
//hello-world/BUILD.bazel
, there is a target that creates ajava_binary
via a macro:❯ buildozer 'print label srcs' //hello-world //hello-world [src/main/java/com/mattnworb/example/Main.java]
but if the macro is made to return something, and that value is assigned to a variable in the BUILD.bazel file, then buildozer can no longer find the rule/target:
even though buildozer can execute the command against the target in question, when expanding wildcards:
I think a part of the issue is that
buildtools/edit/edit.go
Lines 295 to 325 in be1c24c
CallExpr
, and assigning the return value of a macro (which I can't tell is an unorthodox thing to do?) changes that node to anAssignExpr
.The text was updated successfully, but these errors were encountered: