[llvm] r326810 - [Asm] Fix another layering violation in assmebly macro dumping

[David Blaikie via llvm-commits]

Possibly - you probably want to pull in some folks who own/are familiar
with that part of the code base to see if that's appropriate layering here?
(it seems slightly strange to talk about tokens outside the context of a
parser to me - but I guess there's need for it)

On Wed, Mar 14, 2018 at 7:41 AM Roger Pau Monné <royger at freebsd.org> wrote:

> Hello,
>
> Sorry for the delay, I'm finally back home.
>
> On Tue, Mar 06, 2018 at 05:33:18PM +0000, Oliver Stannard wrote:
> > Ah, I see what you mean.
> >
> > The layering violation wasn’t added by my patch, I just turned it into a
> build failure when doing a shared-libraries build.
> >
> > The original layering violation it was committed a few weeks ago:
> https://reviews.llvm.org/rL325139, I’ve added the author and committer of
> that patch.
> >
> > Oliver
> >
> > From: David Blaikie [mailto:dblaikie at gmail.com]
> > Sent: 06 March 2018 17:28
> > To: Pavel Labath
> > Cc: Oliver Stannard; Pavel Labath via llvm-commits
> > Subject: Re: [llvm] r326810 - [Asm] Fix another layering violation in
> assmebly macro dumping
> >
> > Agreed - this is still a layering violation. Including an MCParser
> header from MC violates the dependencies (MCParser depends on MC, not the
> other way around).
>
> So I've been looking into this, and AFAICT the problem is that
> MCAsmMacro.h includes MCParser/MCAsmLexer.h in order to get the
> definition of AsmToken.
>
> Would it be fine to move the definition of AsmToken into
> MC/MCAsmToken.h (and rename AsmToken to MCAsmToken)? I don't see
> AsmToken itself depending on any other MCParser definitions.
>
> Thanks, Roger.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180314/5db6a1af/attachment.html>