search for: sammccall

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 does it a > lot. > > I'd like to try...

...-dev/5rryBKDY8eY) There's at least some desire to reuse this more widely (I just talked to Pavel about LLDB). So I'd propose lifting this up to llvm/Support/JSON.h. (Dependencies are only Support and ADT). Let me know if anyone has concerns! On Fri, Oct 27, 2017 at 9:53 PM Sam McCall <sammccall at google.com> wrote: > 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 >...

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

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,

...= default" is easier to get right d) write a utility specifically for this idiom, e.g. a move-tracking boolean or a UniqueOptional that adds those semantics. In practice unique_ptr is the easiest thing and I don't care about the allocation. On Wed, Jan 24, 2018 at 9:20 PM, Sam McCall <sammccall at google.com> wrote: > > 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 ll...

...rovided 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 case? On Wed, Jan 24, 2018 at 9:20 PM, Sam McCall <sammccall at google.com> wrote: > 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 ty...

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

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,

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