| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The google-default-arguments check normally imposes that virtual
methods have no default arguments. For our use-cases, all
implementations of such methods are expected to use the same
default arguments, and thus this check is manually disabled via
NOLINT comments. However, this is not done consistently.
This commit cleans this up and clarifies our intent by:
- removing the default values (and the NOLINT statement) for all
implementations of virtual methods with default argument values,
matching the desired intended behaviour, but
- keeping the clang-tidy check for future cases where derived
classes would want to provide each different defaults.
|
|
...for skipped individual check.
|
|
|
|
|
|
|
|
... and prepare local execution for clients
using only RBEv2.1 (setting only output_paths).
|
|
|
|
... as it is only needed for local execution, there is no
need to provide it in the common api interface.
|
|
|
|
... as Justbuild has a strict separation between output
files and output directories, but the RBE protocol does
not necessarily maintain such a separation and therefore
does not perform such a verification.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When presenting a build, the output artifacts are hidden behind a
"details" environment to not overload the user with long list of,
e.g., test results (especially if generated by a test matrix). If,
however, only a single artifact is built, there is no reason to
hide it; so simply show it.
|
|
Given the just added json-file formatter, we can generate a diff
formatting properly all json files, i.e., all target, rules, and
expression files, by applying that formatter to every target file
and combining the patches. A target description doing precisely
this can easily be obtained as computed root. In this way, we also
make good use of caching. To avoid doing recomputing the target
description unnecessarily, we factor through the tree structure of
the repository tree; the latter, we obtain from the to-git view of
the top-level directory, whereas for computing the diff we use the
actual (not necessarily committed) files.
|
|
... that is aware of the order-independent fields in our C++ rules.
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
Co-authored-by: Oliver Reiche <oliver.reiche@huawei.com>
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
Co-authored-by: Alberto Sartori <alberto.sartori@huawei.com>
|
|
Our lint target already provides a target for the diff obtained
from clang format. Add a convenience script computing and applying
that patch.
|
|
|
|
|
|
To quickly understand where the problems found by the linter are,
an overall report can be useful, so that
just-mr --main lint build -P REPORT
immediately shows the problems found in the code. For convenience,
also include the patch to be applied to fix formating in the default
target.
|
|
Add a test verifying that no header files are picked up from an
indirect dependency.
|
|
Co-authored-by: Maksim Denisov <denisov.maksim@huawei.com>
Co-authored-by: Paul Cristian Sarbu <paul.cristian.sarbu@huawei.com>
|
|
Remove the test tainting of the distfiles target used in the large
tests and instead make an export target, as it is purely a source
tree. In this way, the distfiles tree can be truly absent and the
large tests can now also be delegated to the serve endpoint.
|
|
- in sequence containers, use operator[] instead of .at() when
accessing indices guaranteed to be in bound;
- in associative containers, prefer .find() and reusing the
returned const iterator to using .contains() and .at(); while
there, make any so obtained iterators const if they are read-only.
|
|
A typical compiler implicitly adds some search directories for system headers; those
might not be obvious for the bootstrapped clang-tidy. Therefore, use the bundled
headers of the clang toolchain. This has the additional advantage, that everyone
uses the same system headers for linting.
|
|
... by explicitly catching any possible exception. Mainly to make clang-tidy
happy.
...
|
|
Due to a random nature of the LargeObjectUtils generator, it may generate 2 identical files in a row. To prevent the test from failing, check that a newly generated file doesn't collide with any already added to the CAS.
|
|
Environment variables can be used to provide some context, why a
particular invocation was run, and hence allow additional sharding.
Also, remind that setting up a cronjob for log rotation might me
a good idea.
|
|
... mentioning that now etc/repos.in.json is used for bootstrapping.
This is relevant for both, determining the precise list of dependencies
needed as well as for patching the repository configuration, e.g.,
in a package build.
|
|
To allow everyone to lint in the same way with minimal manual
setup effort.
|
|
|
|
... using the already-committed configuration file and the
version of clang-tidy that was imported from the toolchain.
|
|
... as repository configuration. We know that everything imported is
not needed for the bootstrap process. Hence, by taking the description
before import, we can avoid fetching unnecessary archives.
|
|
... and make it available to a new "lint" repository. In this way,
there is no dependency of the main or test repository on the newly
importet toolchain, while the "lint" repository has access to a
well-defined version of clang-tidy.
|
|
|
|
|
|
|
|
...that ignores compactification.
|
|
|
|
Linting is a natural example where actions are discovered that are
not neded for the artifact that is requested to be built. Use this
opportunity to explain the difference between discovering an action
and processing it.
|
|
This test uses a file repository at "." with the "to_git" pragma.
Now, if we build the tool to be tested in debug mode, the sources
end up in the test's action directory. If we take the work dir
of the simulated use case top level, all these sources end up
unnecessarily in the workspace root of the test repo. Avoid this
overhead by moving to a subdirectory.
|
|
|
|
|
|
...also on failure or warning.
|
