similar to: RFC: Adding a JSON library to LLVM Support

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

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

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 does it a lot. I'd like to try replacing this with a JSON library. nlohmann/json[1] seems like a reasonable fit: C++11 with exceptions optional, simple build, MIT license. I'd

I've been working on reading and writing yaml encoded documents for the lld project. Michael Spencer added the YAMLParser.h functionality to llvm/Support to help in parsing yaml documents. That parser greatly helps at the syntax level, but you still need to hand write a lot of semantic checking and then convert the various node types in to something usable. I've developed a layer on

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

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

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

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 Tue, Apr 28, 2015 at 3:51 PM, David Majnemer <david.majnemer at gmail.com> wrote: > I love the idea of having some sort of textual representation. My only > concern is that our YAML parser is not very actively maintained (is there > someone expert with its implementation *and* active in the project?) and > (IMHO) over-engineered when compared to the simplicity of our custom

Hi weary warriors of code reviewing, The default homepage in phabricator leaves some things to be desired IMO: - having changes sorted by *creation time* rather than *update time* is a fun way to lose track of things - the LLVM-wide activity feed seems not that useful (though fun) - as soon as a change lands, it becomes fairly hard to find Fortunately phabricator is pretty customizable.

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,

Ah, I tried switching the default, and it doesn't work as I expected. The "My activity" view isn't shown in the menu for logged-out users, but it's still selected as the homepage, so reviews.llvm.org is an error page. This seems like a blocker, I'll file a bug against phabricator. On Tue, Nov 27, 2018 at 2:38 AM Michael Spencer <bigcheesegs 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 like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

json::Value in JSON.h is a discriminated union. The storage is a char array of appropriate type and alignment. The storage holds one object at a time, it's initialized (and for nontrivial types, destroyed) at the right times to ensure this. The cast is only to the type of object that's already there, there's no magic here. On Fri, Aug 10, 2018, 17:52 Andrew Haley <aph at

The coding guidelines say: > Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). This means that functions that just compute or access a value (no side-effects) should be named e.g. `getParent()`, rather than `parent()` as they are in

I did some more extensive testing and found that all GCCs older than 7 trigger the warning, but only if CMAKE_BUILD_TYPE=Release (which I guess indicates optimizations are enabled). There's a patch up for disabling the warning here: https://reviews.llvm.org/D50607. I still feel a little uncomfortable, because I think Jonathan makes an excellent point -- if GCC thinks there's a

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

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

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,