blob: 7215cbe5dd17b906a9d4280b52af0ae8ac0e4074 [file] [log] [blame] [view]
Devon Loehr3d6770f2024-08-19 15:33:591This folder contains scripts for discovering and cataloguing instances of
2compiler warnings in Chromium builds.
3
4### Background
5There are currently many clang warnings which we suppress when building
6Chromium, but intend to one day re-enable (try searching for `-Wno` in
7[build/config/compiler.BUILD.gn](https://source.chromium.org/chromium/chromium/src/+/main:build/config/compiler/BUILD.gn)
8for some examples). Unfortunately, actually turning these warnings back on is a
9daunting task due to the sheer variety of platforms on which chromium needs to
10build. Each of these compiles a different subset of the codebase, meaning that
11certain warnings may only show up when building on a single, obscure system.
12
13The Chromium CQ lets us check for this by building on many different systems
14simultaneously. If we disable the `-Werror` flag, the build logs for each system
15will contain a list of all the warnings that occurred during the build. However,
16the CQ is quite large. It's not feasible to manually inspect the logs for every
17single build to ensure all possible warning sites are caught.
18
19The scripts in this directory serve to automate that process. `pull_logs.py`
20uses the bitbucket cli tool `bb` (which must be in the PATH) to pull the build
21logs for all trybots from a given CQ run, then `collect_warnings.py` can process
22them to determine all the places in the codebase where a warning occurs. With
23that information, it's feasible to begin fixing the occurrences.
24
25### Intended use
26The scripts are flexible, but they are intended for use as part of the following
27workflow:
281. Enable the warning of interest by commenting out the relevant line in the
29 BUILD file.
302. Disable `-Werror` by setting `treat_warnings_as_errors` to `false` in
31 [build/config/compiler/compiler.gni](https://source.chromium.org/chromium/chromium/src/+/main:build/config/compiler/compiler.gni;l=50;drc=e1c0ef1369e527d7027782d1285df483e29a200a).
323. Create a CL with the above changes, and start a CQ Dry Run.
334. When the dry run finishes, run `pull_logs.py` with the CL and patchset number
34 the CQ ran on.
355. When the logs have been downloaded, run `collect_warnings.py` with the
36 warning flag you're interested in.
37
38### Notable script options
39The section describes particularly notable behavior. See the scripts themselves
40for a full list of options. Almost all options have an equivalent single-letter
41form.
42
43`pull_logs.py`
44* The script pulls the build logs for a single trybot step (by default, the
45compilation step). The same step can have different names on different builders,
46so the `--step` argument may be specified multiple times. If so, the scripts
47tries to pull logs from each step name in order until one succeeds.
48* By default, the logs are written to a temporary folder whose name is printed
49to stdout. You can specify the destination with the `--log-dir` argument.
50* The resulting build logs can be extremely large, but most of the lines are
51uninteresting boilerplate. The `--filter` flag may be used to automatically
52remove uninteresting lines before saving the log to disk. The definition of
53"interesting" is controlled by a lambda defined in the script file; by default,
54all lines beginning with `[` are pruned. Feel free to edit the lambda locally
55if you want a different filter.
56* If the `--delete-logs` flag is passed, all `.txt` files in the log
57directory will be deleted before the new ones are downloaded. Not using this
58argument can result in having stale files in the log directory, preventing
59accurate collection of warnings. The argument is disabled by default to prevent
60unintentional deletion of data.
61
62`collect_warnings.py`
63* The `--warning` flag is required to determine which lines correspond to the
64warning of interest. The value of the flag should be the ending text on the line
65where the compiler announces the warning, e.g.
66`--warning [-Wthread-safety-reference-return]`.
67A convenient shortcut to collect all warnings in the file (frequently there will
68only be one type of warning anyway) is to simply pass `--warning ]`.
69* By default, the collected info is written to a temporary file whose name is
70printed to stdout. You can specify your own output file using the `--output`
71argument. If the value is `stdout` or `-`, the text will be printed to
72stdout instead of a file.
73* The scripts has two "modes": by default, it outputs a `.json` file with
74detailed information about each warning emitted. If the `--summarize` flag is
75passed, it will instead output a more human-readable `.txt` file which simply
76lists every warning site, along with a count of number of files and warnings
77emitted total.
78* The detailed information consists of a list of warnings for each source file.
79Each warning entry contains the line and character number, as well as the line
80of code which triggered the warning. Finally, it contains a list of builders on
81which the warning occurred.
82
83### Example invocations
84Pull logs for cl 1234567, patchset 8. Logs will be stored in the default
85location
86(`tools/warning_analysis/build_logs`).
87
88`python3 tools/warning_analysis/pull_logs.py -cl 12345678 -p 8`
89
90Pull logs for cl 1234567, patchset 8. Delete any old logs, filter out
91uninteresting lines from the new logs, and print progress to the console as the
92script is running.
93
94`python3 tools/warning_analysis/pull_logs.py -cl 12345678 -p 8 -d --filter -v`
95
96Collect instances of clang's C++ extension warning from the default
97log location, and store a summary in `thread_safety.txt`.
98
99`python3 tools/warning_analysis/collect_warnings.py -w [-Wvla-cxx-extension] -o cxx_extension --summarize`
100
101Collect instances of any warning, and store the detailed output in `out.json`.
102
103`python3 tools/warning_analysis/collect_warnings.py -w ]`