This is an archive of the discontinued LLVM Phabricator instance.

[clang][cli] Don't emit manufactured warnings
AbandonedPublic

Authored by jansvoboda11 on Feb 17 2021, 1:27 AM.

Details

Summary

The switch from per-member round-trip to whole-CompilerInvocation round-trip in D96280 means we'll be running the extra code present in CompilerInvocation::CreateFromArgs. This code conditionally manufactures extra warnings based on the target and input. This patch ensures we don't generate arguments for such manufactured warnings. Without this patch, each call to CompilerInvocation::generateCC1CommandLine during whole-CompilerInvocation round-trip could generate more arguments than the previous one.

Diff Detail

Event Timeline

jansvoboda11 requested review of this revision.Feb 17 2021, 1:27 AM
jansvoboda11 created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 17 2021, 1:27 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
dexonsmith added inline comments.Feb 17 2021, 12:29 PM
clang/lib/Frontend/CompilerInvocation.cpp
2347–2353

It seems reasonable to skip generating them if they're implied by other command-line options, but I'm not sure "manufactured" is the right word to use as a distinguishing characteristic. The entire CompilerInvocation could have been created programmatically. I suggest instead saying the warning flag is implied by the other command-line options.

Also, note that when created programmatically, one could have pushed stdlibcxx-not-found *after* pushing no-stdlibcxx-not-found. Since that's impossible to recreate, maybe there should be an assertion to catch this? Alternatively, should this kind of imply-diagnostic-options logic be moved to the driver?

Relatedly, unlike most command-line options, GenerateDiagnosticArgs is not canonicalizing the options. For example, if -Wabc implies -Wdef, it'd be nice to generate just -Wabc from initial command-lines of either -Wabc -Wdef or -Wdef -Wabc / to drop the first of -Wno-abc -Wabc / etc.

IMO, something akin to an initial DiagnosticsEngine::DiagState (likely renamed) could be stored in DiagnosticOptions (effectively, the resulting state from calling ProcessWarningOptions). Parsing could translate command-line options to this initial state. The state could be modified programmatically; it'd also be used to initialize DiagnosticsEngine. Generating command-line options would emit a canonical set of options that would recreate the state. But that's a pretty big refactoring, and I think it's okay to make progress without that.

As an initial fix, this is probably fine, but I think the comments and/or FIXMEs should acknowledge that it's a bit fragile and point in a more sound / less fragile direction (doesn't have to be my suggestion).

jansvoboda11 abandoned this revision.Feb 19 2021, 3:22 AM

Abandoning this in favor of D97041 & D97042.

clang/lib/Frontend/CompilerInvocation.cpp
2347–2353

Using "implied" would be fitting as well. I guess I wanted to distinguish this from other implied options that don't need any explicit special-casing.

You're right the way of handling warnings is fragile. Normalizing the arguments into DiagState would be more robust, but as you say, it's a bit more involved. I'm putting that on my back-burner.

In the end, I looked into the history of -Wno-stdlibcxx-not-found and -Wspir-compat more closely and found ways to remove them from CompilerInvocation entirely: D97041 & D97042.