[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Dependencies between tools
From: Ilya Biryukov via cfe-dev <cfe-dev () lists ! llvm ! org>
Date: 2018-04-23 9:10:43
Message-ID: CANmbtFchZr9CjXCHNhAAWu-p=xh3YSK+c+o2jFvBFfAS=imJDg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Apr 19, 2018 at 7:30 PM Chris Gray <chrismgray@google.com> wrote:
> I was assuming that there would be a mechanism for starting asynchronous
> work that could add to the list of diagnostics, but I hadn't gotten there
> yet.
>
Your approach SG, just wanted to make sure we don't block compiler
diagnostics and other features while waiting on clang-tidy results.
We don't have any support for background tasks in clangd, but we should
definitely add them.
If you haven't already, take a look at TUScheduler, it handles the
threading in clangd and background tasks would probably go there.
Let us know if you have any questions along the way, there are certainly
obstacles to making it work.
> I do think that coming up with some sort of way to have inter-tool
> dependencies would be nice regardless of whether it's currently feasible to
> add clang-tidy diagnostics to clangd. (I guess I'm saying that both
> problems will eventually need to be solved, and it makes sense to
> concentrate on them separately.)
>
Totally agree with you, sorry for drifting the conversation away from the
problem at hand.
You're right, all of clang-extra-tools are not structured as libraries. I
guess the most principled approach would to follow LLVM's convention and
move public headers into include/, everything else to lib/, etc.
+Alexander Kornienko <alexfh@google.com>, have you considered extracting a
public library interface for clang-tidy before? Any ideas on how to do it
properly?
> On Thu, Apr 19, 2018 at 3:05 AM Ilya Biryukov <ibiryukov@google.com>
> wrote:
>
>> Hi Chris,
>>
>> Before getting into low-level details, could you elaborate on design
>> you're planning for this?
>> We had plans to integrate clang-tidy before, but it's not as simple as
>> running clang-tidy before reporting diagnostics.
>>
>> Since clang-tidy diagnostics are slow, we want to make sure they don't
>> hurt user-experience of other features.
>> I.e. go-to-definition, compiler diags and code completion should not be
>> blocked or get slower after we add clang-tidy.
>>
>>
>> On Thu, Apr 19, 2018 at 9:20 AM Chris Gray via cfe-dev <
>> cfe-dev@lists.llvm.org> wrote:
>>
>>> Hi, I'm looking into integrating clang-tidy's diagnostics into clangd,
>>> but I'm running into problems because clang-tidy's headers seem effectively
>>> private from clangd's point of view. (I can include
>>> "../clang-tidy/ClangTidy.h", but that seems like a pretty bad hack). Is
>>> there a way that the libraries in tools/extra can export public headers so
>>> that other tools can use them? Or should we be putting the functionality
>>> that we want to share in a library in clang proper?
>>>
>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>
--
Regards,
Ilya Biryukov
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, 2018 at 7:30 \
PM Chris Gray <<a href="mailto:chrismgray@google.com" \
target="_blank">chrismgray@google.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>I was assuming that there would be a \
mechanism for starting asynchronous work that could add to the list of diagnostics, \
but I hadn't gotten there yet. </div></div></blockquote><div>Your approach SG, \
just wanted to make sure we don't block compiler diagnostics and other features \
while waiting on clang-tidy results.</div><div><br></div><div>We don't have any \
support for background tasks in clangd, but we should definitely add \
them.</div><div>If you haven't already, take a look at TUScheduler, it handles \
the threading in clangd and background tasks would probably go there.</div><div>Let \
us know if you have any questions along the way, there are certainly obstacles to \
making it work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I do think that \
coming up with some sort of way to have inter-tool dependencies would be nice \
regardless of whether it's currently feasible to add clang-tidy diagnostics to \
clangd. (I guess I'm saying that both problems will eventually need to be \
solved, and it makes sense to concentrate on them \
separately.)</div></div></blockquote><div>Totally agree with you, sorry for drifting \
the conversation away from the problem at hand.</div><div>You're right, all of \
clang-extra-tools are not structured as libraries. I guess the most principled \
approach would to follow LLVM's convention and move public headers into include/, \
everything else to lib/, etc.</div><div><br></div><div><a class="gmail_plusreply" \
id="plusReplyChip-1" href="mailto:alexfh@google.com" tabindex="-1">+Alexander \
Kornienko</a>, have you considered extracting a public library interface for \
clang-tidy before? Any ideas on how to do it \
properly?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, \
2018 at 3:05 AM Ilya Biryukov <<a href="mailto:ibiryukov@google.com" \
class="m_5180161623058333964m_-8276400033245480835cremed" \
target="_blank">ibiryukov@google.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">Hi Chris,<div><br></div><div>Before getting \
into low-level details, could you elaborate on design you're planning for \
this?</div><div>We had plans to integrate clang-tidy before, but it's not as \
simple as running clang-tidy before reporting \
diagnostics.</div><div><br></div><div>Since clang-tidy diagnostics are slow, we want \
to make sure they don't hurt user-experience of other features.</div><div>I.e. \
go-to-definition, compiler diags and code completion should not be blocked or get \
slower after we add clang-tidy. </div><div><br></div></div><br><div \
class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, \
2018 at 9:20 AM Chris Gray via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" \
class="m_5180161623058333964m_-8276400033245480835cremed" \
target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div></div><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, I'm looking \
into integrating clang-tidy's diagnostics into clangd, but I'm running into \
problems because clang-tidy's headers seem effectively private from clangd's \
point of view. (I can include "../clang-tidy/ClangTidy.h", but that seems \
like a pretty bad hack). Is there a way that the libraries in tools/extra can \
export public headers so that other tools can use them? Or should we be putting the \
functionality that we want to share in a library in clang \
proper?</div></blockquote></div><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> _______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" \
class="m_5180161623058333964m_-8276400033245480835cremed" \
target="_blank">cfe-dev@lists.llvm.org</a><br> <a \
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" \
class="m_5180161623058333964m_-8276400033245480835cremed" \
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br> \
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="m_5180161623058333964m_-8276400033245480835m_-1510112615799932361m_5999517347371075184m_4654588036017413364gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div><div \
dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div> \
</blockquote></div></div></div> </blockquote></div><br clear="all"><div><br></div>-- \
<br><div dir="ltr" class="m_5180161623058333964gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div><div \
dir="ltr"><div>Regards,</div><div>Ilya Biryukov</div></div></div></div></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic