[PATCH] D41357: WIP: Fix Diagnostic layering, moving diagnostics out of Basic

[David Blaikie via Phabricator via cfe-commits]

dblaikie created this revision.
dblaikie added a reviewer: rsmith.
Herald added subscribers: cfe-commits, klimek.

This goes part-way down the path of moving the actual diagnostics out of Clang's Basic library into the respective libraries that use those diagnostics. The end goal would be that a client program calling into those libraries would be responsible for building the necessary table containing all diagnostics from all components they're calling into (so a clang refactoring tool wouldn't need to pull in the codegen diagnostics, for example).

But I ran out of momentum a bit & looking for some sanity checking/help/encouragement/direction.

The basic idea has been to make the static APIs of DiagnosticIDs non-static, then give DiagnosticIDs a ctor that takes the table of diagnostics - as an intermediate step, I've left the no-arg ctor in, and dabbled with making it a bool ctor just as a way to find the places that still use it and clean them up while leaving a handful of correct uses of DiagnosticIDs construction to flesh out (build the table from the desired diagnostics, etc) later.

Partly wondering if this is the right general direction, if some of these changes are worth committing incrementally as I plumb through DiagnosticIDs objects through more APIs.

I remember you, Richard, pointing out that having a generic way to build the diagnostics table based on each different clients needs of different subsets of all diagnostics wasn't going to be pretty owing to the inability to use the preprocessor to conditionally/dynamically #include things in different contexts (I'm sure I'm doing a bad job of explaining that - but I'm understanding what you meant, that there wouldn't be a quick few lines of "define diagnostics table containing these 3 subcomponents" because you'd have to include those 3 subcomponents diagnostic tables in several different contexts to build up several different data structures/subtables/etc... ). & maybe I need to dig into that more, look at how that could end up, see if it's reasonable/good before doing much more here, rather than putting that off until the end.


Repository:
  rC Clang

https://reviews.llvm.org/D41357

Files:
  include/clang/ARCMigrate/ARCMT.h
  include/clang/Basic/DiagnosticIDs.h
  include/clang/CrossTU/CrossTranslationUnit.h
  include/clang/Frontend/LogDiagnosticPrinter.h
  include/clang/Frontend/SerializedDiagnosticPrinter.h
  include/clang/Frontend/TextDiagnosticPrinter.h
  lib/ARCMigrate/ARCMT.cpp
  lib/ARCMigrate/ARCMTActions.cpp
  lib/ARCMigrate/Internals.h
  lib/ARCMigrate/ObjCMT.cpp
  lib/ARCMigrate/PlistReporter.cpp
  lib/Basic/Diagnostic.cpp
  lib/Basic/DiagnosticIDs.cpp
  lib/Basic/Warnings.cpp
  lib/CrossTU/CrossTranslationUnit.cpp
  lib/Driver/Driver.cpp
  lib/Frontend/ChainedIncludesSource.cpp
  lib/Frontend/CompilerInstance.cpp
  lib/Frontend/LogDiagnosticPrinter.cpp
  lib/Frontend/SerializedDiagnosticPrinter.cpp
  lib/Frontend/TextDiagnosticPrinter.cpp
  lib/Sema/Sema.cpp
  lib/Tooling/CompilationDatabase.cpp
  lib/Tooling/Refactoring.cpp
  lib/Tooling/Tooling.cpp
  tools/arcmt-test/arcmt-test.cpp
  tools/clang-rename/ClangRename.cpp
  tools/diagtool/ListWarnings.cpp
  tools/diagtool/ShowEnabledWarnings.cpp
  tools/driver/cc1_main.cpp
  tools/driver/cc1as_main.cpp
  tools/driver/driver.cpp
  tools/libclang/ARCMigrate.cpp
  tools/libclang/CIndex.cpp
  tools/libclang/CIndexDiagnostic.cpp
  tools/libclang/CXStoredDiagnostic.cpp
  unittests/CrossTU/CrossTranslationUnitTest.cpp
  unittests/Tooling/RewriterTestContext.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D41357.127374.patch
Type: text/x-patch
Size: 79933 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171218/8e8adb12/attachment-0001.bin>