| Age | Commit message (Collapse) | Author |
|---|
|
|
|
For a generic rule, it is an error if map union of various
inputs (overlayed in correct order) does not form a proper stage. To
implement this check properly, we first have to construct the map of
all inputs and only then perform the staging check and not do the check
with only the runfiles, as 5e104a526cf76fe75312d2fd288a3c88f506fb0a
accidentally did. Fix this.
|
|
|
|
Now that we generate tree-overlay action identifiers that are disjoint
from identifiers of regular actions, having a joint origin map
does not cause any confusion. Concerning the numbering of subtasks,
we always see tree-overlay actions following the regular actions,
even if defined in a different order. In this way, the identifiers
for the regular actions don't change. Including tree-overlay
actions in the origin map also has the advantage that the origin
is properly reported in case of failure (e.g., non-disjointness of
the obtained trees).
|
|
While our traverser correctly keeps separate identifier spaces for
those entities, having disjoint identifiers allows easier reading
of log messages and more simple reporting of origins of actions.
|
|
|
|
|
|
|
|
In order to stay backwards compatible, the "tree_overlays" entry
in action-graph descriptions is optional.
|
|
... to avoid duplicate log entries.
|
|
The built-in rule "tree" does not support the field "data". Hence
remove it from the list of white-listed fields so that an appropriate
warning is issued if it occurs for that rule.
|
|
If --dump-graph or --dump-plain-graph is given several times, the
action graph wil also be written several times. In this way, regular
use of those options will not be affected by adding them implicitly
through invocation-logging options in the rc file.
|
|
|
|
|
|
While reporting an origin target with action number within that
target describes an action uniquely in a way meaningful to the
user, it might not always be eay to unserstand which precise action
is currently running. For example, for a library with many source
files, we have a target generating a large number of actions and
the association of source file to action number requires detailled
knowledge of the build description. The name of the primary ouput
of that action, on the other hand immediately identifies the file
that is compiled. Therefore, report this as well.
|
|
... and use it when normalizing the origins of actions. For this
task, any well-defined linear order is sufficient. Using a native
comparision (rather than comparing the canonical serialisation)
significantly speeds up that normalisation process, as the assumption
that it would be rare that an action has more than one origin turned
out to be false. In fact, we have seeen cases where this sorting
used to take several seconds before this change, so that this change
reduced analysis time by more than a factor of 5.
|
|
The "generic" rules deliberately resolves conflicts on identical
paths in a latest-wins fashion (seeing all artifacts as later than
all runfiles) to allow an easy way to define actions. However, the
inputs stage obtained by this resolution can still contain conflicts
and those are an error. Properly detect those. Also clarify in the
documentation, that only conflicts on identical paths are resolved
in the described priority, not semantic overlap.
|
|
|
|
|
|
Requires the use of a pragma to avoid wrong removal suggestion for
path_hash.hpp.
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
|
|
|
|
... instead of relying on those dependencies being pulled in
indirectly.
|
|
|
|
|
|
...and private members using lower_case_
|
|
...since we use recursion for trees a lot, but skip this check manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... to avoid regressing there. To be able to enable these
checks also disable a false positive.
|
|
|
|
|
|
...to get the protocol type.
|
|
...with ArtifactDigestFactory::HashDataAs
|
|
... while keeping our .clang-format file.
|
|
|
|
... and also perform conflict check on the normalized paths. Still,
the the output of the "ACTION" funtion be keyed by the representation
of the paths as originally described, to allow the author of a rule
to use non-normalized paths as well.
|
|
... and, in particular, do not include headers of other libraries
that are not even needed.
|
|
! => not; && => and, || => or
|
|
While our local action execution implicitly creates the specified
cwd with the first output file or directory, this behaviour is
not mandated by the remote-execution protocol. There, an action
definition has to ensure that cwd is a directory implied by the
input files. Achieve this, by adding an empty input directory
at cwd if this can be done without creating tree conflicts.
|
|
|
|
|
|
... for the working directory inside the action directory.
|
|
|
|
|
|
|
|
|
