[cfe-dev] Dependencies between tools

[Ilya Biryukov via cfe-dev]

On Thu, Apr 19, 2018 at 7:30 PM Chris Gray <chrismgray at 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 at 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 at 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 at 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 at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>

-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180423/dcb325df/attachment.html>