When scanning dependencies, instead of trying to
skip them based on them being landed, skip them
based on the status of the revision.
Detecting landed revisions is fraught with problems,
as there is no good general way to handle reverts.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
In https://reviews.llvm.org/D123481 we're removing this from the
default builds, but we still want it in CI builds where we know the
platform and compiler configuration.
There are multiple scenarios when script expects to see same branches
and commits. E.g. when upstream commits to release branch trigger
the build.
Reported by Louis Dionne.
This statement adds a VIEW "buildbot_overview" containing all relevant
information for a build. I plan to extend this file with additional
views when needed.
The current setup is configuring the "affected projects" as well
as their dependencies, and run `ninja all` followed by
`ninja check-all`.
This is quite a pessimization for leaf project which don't need to
build and run the tests for their dependencies.
For example a patch affecting only MLIR shouldn't need to build
and run LLVM and clang tests.
This patch changes this by running checks only for the affected
project. For example a patch touching `mlir` is affecting `mlir`
and `flang`. However `flang` depends on `clang`. So the list of
projects to configure is `mlir;flang;clang;llvm;`, but we want
to test only mlir and flang ; we'll run only `ninja check-mlir
check-flang`.
In practice in this example running `ninja all` builds 5658 targets
and `ninja check-all` after that adds 716 more targets. On the other
hands `ninja check-flang check-mlir` results in 3997 targets total.
Concretely the contract with premerge_checks.py is changed so that
the expected argument for the --projects flag is only the list of
affected project, dependencies are automatically added.
"git diff" handles text files encoded that is not valid UTF-8 (e.g
using ISO-8859-1) as text files and produces a diff of those (rather
saying "Binary files a/x and b/x differ").
This means that the diff output may contain such characters. Files
that did would cause clang_tidy_report.py do hit an UnicodeDecodeError
when reading the diff, including if it was on removed lines and
regardless if it was in the ignore file.
By specifying errors mode "replace" for decode() method the bytes
that are not a valid utf-8 encoding are replaced with the unicode
replacement question mark (U+FFFD). When parsing the diff
clang-tidy-diff is only looking at filenames and line numbers of the
diff, so this shouldn't be a problem if it doesn't get the exact same
byte sequence inside the actual change.
