clang might have different warnings than the foreground compiler, and the foreground compiler should have responsibility for reporting those warnings. In addition, the clang background compilation is (normally) done with optimization disabled, which may (and did) cause additional warnings.
The check for whether bitcode generation should be performed was checking both the command name and the command arguments. The reporting of the reasons (via the Event channel) was handled separately, and was out of sync with the detection process. This causes erroneous indications (e.g. pipefailure errors for commands that were uninteresting but also had - arguments for stdin/stdout), did not report all types of events, and could not report some events (e.g. is_response_file was not checked for viability, so the subsequent error reporting would not get invoked). Proper synchronization of these two locations would require extensive status reporting or repetition of previous checks, so instead the issue reporting was merged into the reason checking code.
One difference in behavior is that the previous code could report multiple error issues for a single command, whereas the new code only reports the first issue found. Since any issue is sufficient to prevent bitcode generation, reporting multiple errors isn't really helpful and is possibly even more confusing.
There are some TODO for events in the new code: this is new functionality and will be added in a future PR.
clangmight have different warnings than the foreground compiler, and the foreground compiler should have responsibility for reporting those warnings. In addition, theclangbackground compilation is (normally) done with optimization disabled, which may (and did) cause additional warnings.-arguments for stdin/stdout), did not report all types of events, and could not report some events (e.g.is_response_filewas not checked for viability, so the subsequent error reporting would not get invoked). Proper synchronization of these two locations would require extensive status reporting or repetition of previous checks, so instead the issue reporting was merged into the reason checking code.One difference in behavior is that the previous code could report multiple error issues for a single command, whereas the new code only reports the first issue found. Since any issue is sufficient to prevent bitcode generation, reporting multiple errors isn't really helpful and is possibly even more confusing.
There are some TODO for events in the new code: this is new functionality and will be added in a future PR.