RFC: refactoring clangDriver - diagnostics classes

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
Tl;Dr;
------
We would like to propose a new set of diagnostics classes for the
clangDriver library. A proof-of-concept implementation is available
here: https://reviews.llvm.org/D92025 (more details below).

WHY
===
As mentioned earlier on cfe-dev [1] [2], we are implementing the new
Flang driver. This driver is implemented in terms of clangDriver, which
is great in terms of code re-use across LLVM sub-projects! However, this
also means that:

* Flang depends on Clang
* Clang contains logic that's only relevant to Flang (e.g. [3])

Both of these shortcomings will go away once clangDriver becomes
independent of Clang. In this RFC we focus on one particular dependency
of clangDriver on Clang - *Clang's diagnostics classes*.

DIAGNOSTIC CLASSES
==================
clangDriver relies on Clang's powerful diagnostics classes (e.g.
Diagnostic, DiagnosticsEngine, DiagnosticConsumer, DiagnosticBuilder)
for its relatively basic command-line errors and warnings. These classes:

* are tuned for complex frontend/language diagnostics (i.e. related to
parsing,  semantic analysis or for clang-tidy checks)
* cater for _many_ scenarios, e.g. there 17 overloads for `operator<<`
for `DiagnosticBuilder` (defined in Diagnostic.h), but clangDriver only
requires 2 (for `const char * Str` and for `StringRef`)
* implement complex logic for tracking source locations (macro
definition vs macro expansion, template declaration vs template
instantiation), which are never used in clangDriver

Basically, the usage of Clang's diagnostics in clangDriver is _very_
limited.

OLD APPROACH - thin abstraction layer
=====================================
In [2] we proposed to create a thin abstraction layer above Clang's
diagnostics classes. That abstraction layer would satisfy the
requirements of clangDriver, but otherwise it would be independent of
Clang. We are now discovering that the integration of diagnostics
classes and Clang's frontend is deeper than we originally thought. This
integration has recently become even deeper:

* https://reviews.llvm.org/D84362

In my post commit review I tried highlighting why we think that that
patch makes our original approach infeasible. We are now re-evaluating
our original approach and would appreciate your feedback.

NEW APPROACH - independent set of classes
=========================================
Instead, we would like to propose a new set of diagnostics classes for
clangDriver, e.g.

* DriverDiagnostic, DriverDiagnosticsEngine, DriverDiagnosticConsumer,
DriverDiagnosticBuilder.

These classes would be _much_ simplified versions of Clang's current
diagnostic classes:

* initially independent of Clang's diagnostics classes (commonalities
will naturally emerge and eventually there will be shared infrastructure)
* will only contain driver diagnostics, i.e. DiagnosticDriverKinds.td
(conversely, these diagnostics will no longer be available in the
frontend, i.e. in clangBasic)
* only warnings and errors will be supported (no other diagnostics are
currently generated in clangDriver)
* no concept of source location will be supported

In other words, this would be a set of trivial clones of the current
diagnostics infrastructure.

PROOF-OF-CONCEPT
================
A proof-of-concept implementation of the proposed approach is available
here: https://reviews.llvm.org/D92025. It contains:

* a new library, clangDriverDiagnostics (based on diagnostics classes
from clangBasic)
* changes in clangDriver and the Flang driver so that diagnostics from
clangDriverDiagnostics are used instead of those from clangBaisc

It builds fine and the behaviour of the new Flang driver (flang-new)
remains unchanged. We haven't updated clang yet and we've not tried
trimming clangDriverDiagnostics too much. Currently it's just slightly
simplified version of diagnostics from clangBasic. We'd need to refactor
the contents of clang/tools/driver/ first to have a complete list of the
required features. That's obviously going to be much tricker than the
Flang driver. We wanted to get some initial feedback before attempting that.

QUESTION
========
What do you think about this approach? Is there anything that we missed?
Your comments and feedback are much appreciated!

Thank you for reading!

On behalf of the Arm Fortran Team,
-Andrzej

[1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
[2] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[3]
https://github.com/llvm/llvm-project/blob/006b3bdeddb0234f53a1ab72e427ef74184461f5/clang/lib/Driver/Driver.cpp#L216
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
On Tue, Nov 24, 2020 at 7:40 AM Andrzej Warzynski via cfe-dev
<[hidden email]> wrote:

>
> Tl;Dr;
> ------
> We would like to propose a new set of diagnostics classes for the
> clangDriver library. A proof-of-concept implementation is available
> here: https://reviews.llvm.org/D92025 (more details below).
>
> WHY
> ===
> As mentioned earlier on cfe-dev [1] [2], we are implementing the new
> Flang driver. This driver is implemented in terms of clangDriver, which
> is great in terms of code re-use across LLVM sub-projects! However, this
> also means that:
>
> * Flang depends on Clang
> * Clang contains logic that's only relevant to Flang (e.g. [3])
>
> Both of these shortcomings will go away once clangDriver becomes
> independent of Clang. In this RFC we focus on one particular dependency
> of clangDriver on Clang - *Clang's diagnostics classes*.
>
> DIAGNOSTIC CLASSES
> ==================
> clangDriver relies on Clang's powerful diagnostics classes (e.g.
> Diagnostic, DiagnosticsEngine, DiagnosticConsumer, DiagnosticBuilder)
> for its relatively basic command-line errors and warnings. These classes:
>
> * are tuned for complex frontend/language diagnostics (i.e. related to
> parsing,  semantic analysis or for clang-tidy checks)

Sorry for the slight distraction, but what's the plan for Flang's
diagnostics? Might it benefit from Clang's diagnostic infrastructure
for tracking source locations, etc?

> * cater for _many_ scenarios, e.g. there 17 overloads for `operator<<`
> for `DiagnosticBuilder` (defined in Diagnostic.h), but clangDriver only
> requires 2 (for `const char * Str` and for `StringRef`)
> * implement complex logic for tracking source locations (macro
> definition vs macro expansion, template declaration vs template
> instantiation), which are never used in clangDriver
>
> Basically, the usage of Clang's diagnostics in clangDriver is _very_
> limited.
>
> OLD APPROACH - thin abstraction layer
> =====================================
> In [2] we proposed to create a thin abstraction layer above Clang's
> diagnostics classes. That abstraction layer would satisfy the
> requirements of clangDriver, but otherwise it would be independent of
> Clang. We are now discovering that the integration of diagnostics
> classes and Clang's frontend is deeper than we originally thought. This
> integration has recently become even deeper:
>
> * https://reviews.llvm.org/D84362
>
> In my post commit review I tried highlighting why we think that that
> patch makes our original approach infeasible. We are now re-evaluating
> our original approach and would appreciate your feedback.
>
> NEW APPROACH - independent set of classes
> =========================================
> Instead, we would like to propose a new set of diagnostics classes for
> clangDriver, e.g.
>
> * DriverDiagnostic, DriverDiagnosticsEngine, DriverDiagnosticConsumer,
> DriverDiagnosticBuilder.
>
> These classes would be _much_ simplified versions of Clang's current
> diagnostic classes:
>
> * initially independent of Clang's diagnostics classes (commonalities
> will naturally emerge and eventually there will be shared infrastructure)
> * will only contain driver diagnostics, i.e. DiagnosticDriverKinds.td
> (conversely, these diagnostics will no longer be available in the
> frontend, i.e. in clangBasic)
> * only warnings and errors will be supported (no other diagnostics are
> currently generated in clangDriver)
> * no concept of source location will be supported
>
> In other words, this would be a set of trivial clones of the current
> diagnostics infrastructure.
>
> PROOF-OF-CONCEPT
> ================
> A proof-of-concept implementation of the proposed approach is available
> here: https://reviews.llvm.org/D92025. It contains:
>
> * a new library, clangDriverDiagnostics (based on diagnostics classes
> from clangBasic)
> * changes in clangDriver and the Flang driver so that diagnostics from
> clangDriverDiagnostics are used instead of those from clangBaisc
>
> It builds fine and the behaviour of the new Flang driver (flang-new)
> remains unchanged. We haven't updated clang yet and we've not tried
> trimming clangDriverDiagnostics too much. Currently it's just slightly
> simplified version of diagnostics from clangBasic. We'd need to refactor
> the contents of clang/tools/driver/ first to have a complete list of the
> required features. That's obviously going to be much tricker than the
> Flang driver. We wanted to get some initial feedback before attempting that.
>
> QUESTION
> ========
> What do you think about this approach? Is there anything that we missed?
> Your comments and feedback are much appreciated!
>
> Thank you for reading!
>
> On behalf of the Arm Fortran Team,
> -Andrzej
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
> [2] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
> [3]
> https://github.com/llvm/llvm-project/blob/006b3bdeddb0234f53a1ab72e427ef74184461f5/clang/lib/Driver/Driver.cpp#L216
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev


On 24/11/2020 18:00, David Blaikie wrote:
>
> Sorry for the slight distraction, but what's the plan for Flang's
> diagnostics? Might it benefit from Clang's diagnostic infrastructure
> for tracking source locations, etc?
>

No worries. We discussed this briefly in the past (see e.g. [1]). AFAIK,
there are no plans to share diagnostics infra between Clang and Flang.

Diagnostics (and SourceLocation) in Clang are tuned for C-family
languages. Generalising that code would be non-trivial. Personally I
think that such code re-use would be great, but sadly we wouldn't be
able to commit to such refactoring anytime soon.

[1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/142024.html

-Andrzej
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
On Tue, Nov 24, 2020 at 10:58 AM Andrzej Warzynski
<[hidden email]> wrote:

>
>
>
> On 24/11/2020 18:00, David Blaikie wrote:
> >
> > Sorry for the slight distraction, but what's the plan for Flang's
> > diagnostics? Might it benefit from Clang's diagnostic infrastructure
> > for tracking source locations, etc?
> >
>
> No worries. We discussed this briefly in the past (see e.g. [1]). AFAIK,
> there are no plans to share diagnostics infra between Clang and Flang.
>
> Diagnostics (and SourceLocation) in Clang are tuned for C-family
> languages. Generalising that code would be non-trivial. Personally I
> think that such code re-use would be great, but sadly we wouldn't be
> able to commit to such refactoring anytime soon.
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/142024.html

Hmm - given the answer here:
http://lists.llvm.org/pipermail/llvm-dev/2020-June/142048.html - I
wonder whether it's likely there should/would be more code reuse.
Sharing the whole integrated assembler between clang and flang? I
don't see further discussion on that branch of the thread engaging
with that idea.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev


On 24/11/2020 20:18, David Blaikie wrote:

> On Tue, Nov 24, 2020 at 10:58 AM Andrzej Warzynski
> <[hidden email]> wrote:
>>
>>
>>
>> On 24/11/2020 18:00, David Blaikie wrote:
>>>
>>> Sorry for the slight distraction, but what's the plan for Flang's
>>> diagnostics? Might it benefit from Clang's diagnostic infrastructure
>>> for tracking source locations, etc?
>>>
>>
>> No worries. We discussed this briefly in the past (see e.g. [1]). AFAIK,
>> there are no plans to share diagnostics infra between Clang and Flang.
>>
>> Diagnostics (and SourceLocation) in Clang are tuned for C-family
>> languages. Generalising that code would be non-trivial. Personally I
>> think that such code re-use would be great, but sadly we wouldn't be
>> able to commit to such refactoring anytime soon.
>>
>> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/142024.html
>
> Hmm - given the answer here:
> http://lists.llvm.org/pipermail/llvm-dev/2020-June/142048.html - I
> wonder whether it's likely there should/would be more code reuse.
> Sharing the whole integrated assembler between clang and flang? I
> don't see further discussion on that branch of the thread engaging
> with that idea.
>


Thank you for your reply. I appreciate that there are other important
parts of the toolchain that we haven't discussed in much detail yet. For
now we've been focusing on the driver. Are you suggesting that perhaps
we shouldn't be sharing/re-using clangDriver? Or have a broader
discussion about other infrastructure instead?

I'm just trying to understand whether we've missed some important step
or dependency here. From what we've seen and discussed so far, it seems
that making clangDriver independent of Clang would be beneficial for
both Clang and Flang.

Btw, we continued the original discussion in this follow-up RFC:
* http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html


-Andrzej
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
On Wed, Nov 25, 2020 at 8:26 AM Andrzej Warzynski
<[hidden email]> wrote:

>
>
>
> On 24/11/2020 20:18, David Blaikie wrote:
> > On Tue, Nov 24, 2020 at 10:58 AM Andrzej Warzynski
> > <[hidden email]> wrote:
> >>
> >>
> >>
> >> On 24/11/2020 18:00, David Blaikie wrote:
> >>>
> >>> Sorry for the slight distraction, but what's the plan for Flang's
> >>> diagnostics? Might it benefit from Clang's diagnostic infrastructure
> >>> for tracking source locations, etc?
> >>>
> >>
> >> No worries. We discussed this briefly in the past (see e.g. [1]). AFAIK,
> >> there are no plans to share diagnostics infra between Clang and Flang.
> >>
> >> Diagnostics (and SourceLocation) in Clang are tuned for C-family
> >> languages. Generalising that code would be non-trivial. Personally I
> >> think that such code re-use would be great, but sadly we wouldn't be
> >> able to commit to such refactoring anytime soon.
> >>
> >> [1] http://lists.llvm.org/pipermail/llvm-dev/2020-June/142024.html
> >
> > Hmm - given the answer here:
> > http://lists.llvm.org/pipermail/llvm-dev/2020-June/142048.html - I
> > wonder whether it's likely there should/would be more code reuse.
> > Sharing the whole integrated assembler between clang and flang? I
> > don't see further discussion on that branch of the thread engaging
> > with that idea.
> >
>
>
> Thank you for your reply. I appreciate that there are other important
> parts of the toolchain that we haven't discussed in much detail yet. For
> now we've been focusing on the driver. Are you suggesting that perhaps
> we shouldn't be sharing/re-using clangDriver? Or have a broader
> discussion about other infrastructure instead?

It sounded like Richard was saying in the other thread, that if flang
was going to share the integrated preprocessor - then the amount of
code shared would be quite large and maybe flang depending on clang
would be the right solution to that, if that's the direction we're
going in.

But I didn't see any discussion of if flang would share that, or if
not, why not. If it is going to - then the driver refactoring may be
unnecessary, because the goal of flang not depending on clang might
not be suitable in a future in which flang shares clang's
preprocessor.

> I'm just trying to understand whether we've missed some important step
> or dependency here. From what we've seen and discussed so far, it seems
> that making clangDriver independent of Clang would be beneficial for
> both Clang and Flang.
>
> Btw, we continued the original discussion in this follow-up RFC:
> * http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
>
>
> -Andrzej
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev


On 25/11/2020 21:39, David Blaikie wrote:

>
> It sounded like Richard was saying in the other thread, that if flang
> was going to share the integrated preprocessor - then the amount of
> code shared would be quite large and maybe flang depending on clang
> would be the right solution to that, if that's the direction we're
> going in.

Our goal has always been _just the driver_.

In the follow-up RFC [1], we refined our plan and tried to emphasise
that our plan is to:
  "Make libclangDriver independent of Clang".
Richard's reply to that RFC [2]: "(...) this seems like a good direction
to me". Hopefully Richard (CC'ed) can confirm that we didn't
misinterpret that :)

I don't think that Flang should depend on Clang. Also, that's something
that was explicitly requested in one of our early patches for the new
Flang driver [4]. And indeed, we committed ourselves to removing this
dependency on flang-dev [5]. As for cfe-dev, in both [1] and [3] we
proposed to move any shared code (in particular, libClangDriver) out of
Clang. So again, no dependency on Clang.

AFAIK, there are no plans to share the preprocessor and hence no
discussion in that direction is happening. Obviously I can't speak for
everyone on flang-dev, so I CC'ed that mailing list for better visibility.


Thank you for your feedback!

-Andrzej


[1] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[2] http://lists.llvm.org/pipermail/cfe-dev/2020-August/066488.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
[4] https://reviews.llvm.org/D79092
[5] http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
FWIW, agreement on the rough plan to split clang driver from the rest of clang was certainly how I remember the previous thread ending, and it still seems like a reasonable idea to me.

On Thu, Nov 26, 2020, 12:04 PM Andrzej Warzynski via cfe-dev <[hidden email]> wrote:


On 25/11/2020 21:39, David Blaikie wrote:

>
> It sounded like Richard was saying in the other thread, that if flang
> was going to share the integrated preprocessor - then the amount of
> code shared would be quite large and maybe flang depending on clang
> would be the right solution to that, if that's the direction we're
> going in.

Our goal has always been _just the driver_.

In the follow-up RFC [1], we refined our plan and tried to emphasise
that our plan is to:
  "Make libclangDriver independent of Clang".
Richard's reply to that RFC [2]: "(...) this seems like a good direction
to me". Hopefully Richard (CC'ed) can confirm that we didn't
misinterpret that :)

I don't think that Flang should depend on Clang. Also, that's something
that was explicitly requested in one of our early patches for the new
Flang driver [4]. And indeed, we committed ourselves to removing this
dependency on flang-dev [5]. As for cfe-dev, in both [1] and [3] we
proposed to move any shared code (in particular, libClangDriver) out of
Clang. So again, no dependency on Clang.

AFAIK, there are no plans to share the preprocessor and hence no
discussion in that direction is happening. Obviously I can't speak for
everyone on flang-dev, so I CC'ed that mailing list for better visibility.


Thank you for your feedback!

-Andrzej


[1] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
[2] http://lists.llvm.org/pipermail/cfe-dev/2020-August/066488.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
[4] https://reviews.llvm.org/D79092
[5] http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [flang-dev] RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
In reply to this post by Dimitry Andric via cfe-dev
Regarding sharing a preprocessor between flang and clang, I think there wasn't much discussion about it because no one has an interest in doing it.

Preprocessing is superficially similar but Fortran has a lot of differences that would make sharing with clang very difficult.
Some examples of things a Fortran preprocessor has to handle:
- fixed form vs. free form and directives that switch between them
- preprocessor directives in all-caps in fixed form
- source lines truncated at or padded to 72 or 132 columns
- Fortran line continuations
- Hollerith constants and edit descriptors
- Fortran expressions in #if and #elif
- Fortran INCLUDE lines

There are more details about Fortran preprocessing here:
https://github.com/llvm/llvm-project/blob/master/flang/docs/Preprocessing.md

Tim

On 11/26/20, 9:04 AM, "flang-dev on behalf of Andrzej Warzynski via flang-dev" <[hidden email] on behalf of [hidden email]> wrote:

    External email: Use caution opening links or attachments


    On 25/11/2020 21:39, David Blaikie wrote:

    >
    > It sounded like Richard was saying in the other thread, that if flang
    > was going to share the integrated preprocessor - then the amount of
    > code shared would be quite large and maybe flang depending on clang
    > would be the right solution to that, if that's the direction we're
    > going in.

    Our goal has always been _just the driver_.

    In the follow-up RFC [1], we refined our plan and tried to emphasise
    that our plan is to:
      "Make libclangDriver independent of Clang".
    Richard's reply to that RFC [2]: "(...) this seems like a good direction
    to me". Hopefully Richard (CC'ed) can confirm that we didn't
    misinterpret that :)

    I don't think that Flang should depend on Clang. Also, that's something
    that was explicitly requested in one of our early patches for the new
    Flang driver [4]. And indeed, we committed ourselves to removing this
    dependency on flang-dev [5]. As for cfe-dev, in both [1] and [3] we
    proposed to move any shared code (in particular, libClangDriver) out of
    Clang. So again, no dependency on Clang.

    AFAIK, there are no plans to share the preprocessor and hence no
    discussion in that direction is happening. Obviously I can't speak for
    everyone on flang-dev, so I CC'ed that mailing list for better visibility.


    Thank you for your feedback!

    -Andrzej


    [1] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
    [2] http://lists.llvm.org/pipermail/cfe-dev/2020-August/066488.html
    [3] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
    [4] https://reviews.llvm.org/D79092
    [5] http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
    _______________________________________________
    flang-dev mailing list
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: refactoring clangDriver - diagnostics classes

Dimitry Andric via cfe-dev
In reply to this post by Dimitry Andric via cfe-dev
Thanks for the context and links (& for Tim's follow-up as well,
though I don't understand most of the terms/Fortran features he
mentioned) & apologies again for the diversion.

At least a rough glance at the patch makes sense to me within this context.

On Thu, Nov 26, 2020 at 9:03 AM Andrzej Warzynski
<[hidden email]> wrote:

> On 25/11/2020 21:39, David Blaikie wrote:
> > It sounded like Richard was saying in the other thread, that if flang
> > was going to share the integrated preprocessor - then the amount of
> > code shared would be quite large and maybe flang depending on clang
> > would be the right solution to that, if that's the direction we're
> > going in.
>
> Our goal has always been _just the driver_.
>
> In the follow-up RFC [1], we refined our plan and tried to emphasise
> that our plan is to:
>   "Make libclangDriver independent of Clang".
> Richard's reply to that RFC [2]: "(...) this seems like a good direction
> to me". Hopefully Richard (CC'ed) can confirm that we didn't
> misinterpret that :)
>
> I don't think that Flang should depend on Clang. Also, that's something
> that was explicitly requested in one of our early patches for the new
> Flang driver [4]. And indeed, we committed ourselves to removing this
> dependency on flang-dev [5]. As for cfe-dev, in both [1] and [3] we
> proposed to move any shared code (in particular, libClangDriver) out of
> Clang. So again, no dependency on Clang.
>
> AFAIK, there are no plans to share the preprocessor and hence no
> discussion in that direction is happening. Obviously I can't speak for
> everyone on flang-dev, so I CC'ed that mailing list for better visibility.
>
>
> Thank you for your feedback!
>
> -Andrzej
>
>
> [1] http://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html
> [2] http://lists.llvm.org/pipermail/cfe-dev/2020-August/066488.html
> [3] http://lists.llvm.org/pipermail/llvm-dev/2020-June/141994.html
> [4] https://reviews.llvm.org/D79092
> [5] http://lists.llvm.org/pipermail/flang-dev/2020-July/000470.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev