Skip to content

NullPointerException using rustfmt_aspect with custom verilog_lint_test rule #1428

Open
@espeer-enfabrica

Description

@espeer-enfabrica

Originally logged here: bazelbuild/bazel#15753

We see the following splat:

FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node '[]#@rules_rust//rust/private:rustfmt.bzl%rustfmt_aspect BuildConfigurationValue.Key[614a8816f292c11cb4ef63601cc72f3c9ff3ca3f749cc82148f834a38f437e65] ConfiguredTargetKey{label=//hw/projects/mlm/dv/csr/mem_wrapper/pmw:pmw_blk_ram1_lint, config=BuildConfigurationValue.Key[614a8816f292c11cb4ef63601cc72f3c9ff3ca3f749cc82148f834a38f437e65]} {}' (requested by nodes 'com.google.devtools.build.lib.skyframe.AspectKeyCreator$TopLevelAspectsKey@d4cddab9')
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:674)
at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:382)
at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at net.starlark.java.eval.Starlark.checkValid(Starlark.java:112)
at net.starlark.java.eval.Dict$Builder.put(Dict.java:434)
at com.google.devtools.build.lib.analysis.starlark.StarlarkAttributesCollection$Builder.addAttribute(StarlarkAttributesCollection.java:227)
at com.google.devtools.build.lib.analysis.starlark.StarlarkRuleContext.(StarlarkRuleContext.java:277)
at com.google.devtools.build.lib.analysis.RuleContext.initStarlarkRuleContext(RuleContext.java:1151)
at com.google.devtools.build.lib.skyframe.StarlarkAspectFactory.create(StarlarkAspectFactory.java:52)
at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createAspect(ConfiguredTargetFactory.java:536)
at com.google.devtools.build.lib.skyframe.AspectFunction.createAspect(AspectFunction.java:867)
at com.google.devtools.build.lib.skyframe.AspectFunction.compute(AspectFunction.java:464)
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:590)
... 7 more

when rules_rust's rustfmt_aspect is configured in bazelrc as follows:

build --aspects=@rules_rust//rust:defs.bzl%rustfmt_aspect
build --output_groups=+rustfmt_checks
build --@rules_rust//:rustfmt.toml=//:.rustfmt.toml

This happens when the aspect is combined with our internal verilog_lint_test rule and something we feed Bazel makes it unhappy (details omitted):

_verilog_lint_test = rule(
    implementation = _verilog_lint_test_impl,
    test = True,
    attrs = {
    # ...
    # ...
    # ...
)

and:

def _verilog_lint_test_impl(ctx):
    # ...
    # ...
    # ...
    print("test script %s" % test_script)
    print("runfiles %s" % runfiles)
    return [DefaultInfo(runfiles = runfiles, executable = test_script)]

Those two prints happen before the splat:

DEBUG: /home/edwin/internal/bazel/eda/verilog.bzl:527:10: test script <generated file hw/projects/mlm/dv/csr/mem_wrapper/pmw/rerooted-pmw_blk_ram1_lint>
DEBUG: /home/edwin/internal/bazel/eda/verilog.bzl:528:10: runfiles Analyzing: target //hw/projects/mlm/dv/csr/mem_wrapper/pmw:pmw_blk_ram1_lint (133 packages loaded, 3903 targets configured)

I don't know enough about what Bazel expects the rule to return to know if the return value is legal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions