similar to: Adding a third-party dependency in clang-tools-extra

On Oct 19, 2017 6:50 PM, "Chandler Carruth" <chandlerc at google.com> wrote: On Thu, Oct 19, 2017 at 3:48 AM Sam McCall <sammccall at google.com> wrote: > clangd communicates with an editor via JSON-RPC. It parses JSON with > YAMLParser, which is awkward, and generates JSON with printf and friends, > which is miserable. Much of LLVM does things this way, but clangd

We don't have a dedicated JSON library in the LLVM tree, I'd like to add one. The pressing need is for clangd, but we have other tools that read/write JSON too. I'm proposing we write a new one, rather than importing a third-party library (licensing/integration reasons), on or extending YamlParser/YamlIO (usability/flexibility). I lean towards a design that parses a full DOM at once,

Finally following up here... We ended up writing a JSON parser and checking it in under clangd/. We've been using that for a while now without hitting new problems. The header is here: https://reviews.llvm.org/source/clang-tools-extra/browse/clang-tools-extra/trunk/clangd/JSONExpr.h It's a DOM-based approach with objects on the heap. There's no streaming parser, though one could be

Hi, I'm a new contributor. I'm considering the possibility of adopting a third-party JSON library instead of LLVM's homegrown `lib/Support/JSON.cpp`. The way I see it, this would bring several advantages as well as some downsides: + Slimmer codebase. + Benefit from upstream work and active contributions to another project. + Possibly improved performance and API ergonomics. -

+llvm-dev On Mon, Jan 14, 2019 at 1:46 PM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 14/01/2019 10:36, Ilya Biryukov via llvm-dev wrote: > > To reiterate, our proposal was to create a repository for each of the > > LLVM subprojects under the official LLVM GitHub account, e.g. > > github.com/llvm/clangd <http://github.com/llvm/clangd>. > >

Hi LLVM community, As discussed earlier, we in the clangd land feel that buganizer does not address the clangd's needs as a bug-tracking system. In our previous attempt to raise this on llvm-dev [1] we shared our idea to put the clangd issue tracker on GitHub. The participants raised multiple concerns, including the migration costs, whether GitHub is the right choice as an issue tracker,

On Fri, Dec 13, 2019 at 2:12 PM Chris Bieneman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Dec 12, 2019, at 5:58 AM, Sam McCall via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Short version: clangd would like to be able to build a client+server that > can make RPCs across the internet. An RPC system isn't a trivial dependency > and

Short version: clangd would like to be able to build a client+server that can make RPCs across the internet. An RPC system isn't a trivial dependency and rolling our own from scratch isn't appealing. Have other projects had a need for this? Any advice on how to approach such dependencies? -- Longer: clangd (a language server, like an IDE backend) builds an index of the project you're

On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this! > > Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side). > As such I don't

I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) https://reviews.llvm.org/D54277 proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some filesystem

Hello, I started using clangd to get better static analysis and code refactoring tooling with the R sources (using eglot-mode in Emacs, it just works once you've generated a `compile_commands.json` file with `bear make all`). I noticed that the static analyser can't understand several header files because these are not self-contained. So I went through all .h files and inserted the

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,

Hello, When running test-release.sh using GCC 5.4.0 we encountered this error : /home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp: In function ‘llvm::StringLiteral clang::clangd::{anonymous}::getNameForExpr(const clang::Expr*)’: /home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp:450:10: error: could not convert

As a part of upcoming new Clangd symbol index implementation, we would like to start support benchmarks of different Clangd pieces, such as index queries and code completion. There are already two projects in the LLVM tree using google/benchmark library while keeping its source code in-tree: libcxx (libcxx/utils/google-benchmark) and test-suite (test-suite/MicroBenchmarks/libs/benchmark-1.3.0).

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

People have let me know that the attachment didn't make it through. Do patches get filtered out? Please find it there: https://github.com/lionel-/r-svn/commit/e3de56798b1321a3fa8688a42bbb73d763b78024.patch I'm also happy to post it on the bugzilla if that makes sense. Best, Lionel On 3/16/23, Lionel Henry <lionel at posit.co> wrote: > Hello, > > I started using clangd to

I'm happy to have this in the main LLVM repositiory. The version in the test suite should likely stay there because the test suite should be buildable w/o LLVM itself -- it is largely a distinct thing. We re-use lit, but not much else from LLVM, and we wouldn't want to install the benchmark library the way we do lit. One interesting point: we should have some way of running the in-tree

Why does GN bot still send mails? I thought it got fixed? On Wed, Jul 3, 2019 at 1:44 PM <llvm.buildmaster at lab.llvm.org> wrote: > > The Buildbot has detected a new failure on builder sanitizer-x86_64-linux-gn while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/1820 > > Buildbot URL:

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

I still need answer to my question about how to make sure that libcxx and libcxxabi are also built after enabling them, but I have another problem right now. I want to know how to link third-party libraries into my code using the lld linker. I have this code: https://github.com/DragonOsman/currency_converter