[cfe-dev] Cleanup on aisle DebugInfo enums

[David Blaikie via cfe-dev]

Sounds plausible.

(just to check: what's the motivation not to use the LLVM versions of these
enums if they match the desired semantics? (I imagine there are many good
reasons not to use them, just figure it's worth writing down in this thread
so it's clear for historic purposes))

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/7836f065/attachment.html>