Recent experience with symbolic macro migration showed that we need to relax the restrictions on the implicit creation of input files.
Previously it was an error to refer to a non-existent target "foo_input" if there happened to be a symbolic macro named "foo" in the package. The rationale was that we don't want to have to evaluate foo just to decide whether or not foo_input is in fact an InputFile.
But this restriction means that the common idiom:
bzl_library(
name = "foo",
srcs = ["foo.bzl"],
)
blocks bzl_library from being a symbolic macro (e.g. wrapping the underlying rule). We believe this will be a common blocker well beyond this one example.
Therefore, we will now only block the implicit creation of input files when they collide exactly with a target or macro, and not when they merely fall within a macro's namespace.
A consequence of this design change is that it complicates how input files are handled when we have lazy macro evaluation. But we'll deal with that when the time comes.
brandjon
commented
3 hours ago
Recent experience with symbolic macro migration showed that we need to relax the restrictions on the implicit creation of input files.
Previously it was an error to refer to a non-existent target
"foo_input"if there happened to be a symbolic macro named"foo"in the package. The rationale was that we don't want to have to evaluatefoojust to decide whether or notfoo_inputis in fact anInputFile.But this restriction means that the common idiom:
blocks
bzl_libraryfrom being a symbolic macro (e.g. wrapping the underlying rule). We believe this will be a common blocker well beyond this one example.Therefore, we will now only block the implicit creation of input files when they collide exactly with a target or macro, and not when they merely fall within a macro's namespace.
A consequence of this design change is that it complicates how input files are handled when we have lazy macro evaluation. But we'll deal with that when the time comes.