[cfe-dev] Cleanup on aisle DebugInfo enums

[Reid Kleckner via cfe-dev]

In general, I'm in favor of putting most of our options types in Basic, so
this sounds good.

On Fri, Feb 5, 2016 at 10:57 AM, Robinson, Paul via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> In r259489, Benny Kramer moved the DebugInfoKind enum into its own
> header, include/clang/Driver/DebugInfoKind.h. This was to prevent
> Driver from pulling in headers from Frontend.  However, this leaves
> the enum in kind of a weird place, I think Basic would be better (and
> not re-introduce the problem Benny was solving).
>
> Wondering why the tuning enum didn't cause the same problem, I found
> that when I created the Clang enum, I didn't make Driver use it; it's
> still using the LLVM version of the enum.  While this is not
> technically wrong (you could rearrange the values and it would do no
> harm) it's an inconsistency within Clang.
>
> But, if I make Driver use the tuning enum from Clang's CodeGenOptions,
> then we'll have the same problem that prompted r259489 in the first
> place--Driver depending on Frontend. Rather than create Yet Another
> Header, it would be convenient to put the tuning enum in the same
> place as DebugInfoKind, as they are topically related and commonly
> used in the same places.
>
> I propose to do the following:
>
> Patch #1 (totally mechanical)
> - move DebugInfoKind.h from Driver to Basic
> - rename it to DebugInfoOptions.h
> This will take care of all the #include renaming in one go.
>
> Patch #2 (basically mechanical)
> - move the DebuggerKind enum from CodeGenOptions.h to DebugInfoOptions.h
> - fix up Driver to use this enum instead of the LLVM equivalent.
>
> Or I can do it all at once, the combined patch would still be
> reasonable I think.
>
> Sound okay?
> --paulr
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160205/f151fda3/attachment.html>