similar to: Proposal for an alternative bugtracking workflow

Well, it's not really critical for us _now_, because we have not switched to github issues. And I can't really see any possibility of that happening in the short-term, either. Even once we do decide we want to move that way -- which we haven't yet even done -- it'll be a long road to making it happen, and I suspect there's many more critical missing features that we'll

+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>. > >

On Tue, Jan 15, 2019 at 1:47 PM Chandler Carruth <chandlerc at gmail.com> wrote: > Has anyone reached out to GitHub about potentially enabling this? > For the lack of a better place, filed a ticker against GitHub support. Will update the thread when they come back to me. -- Regards, Ilya Biryukov -------------- next part -------------- An HTML attachment was scrubbed... URL:

The script queries **all** issues with specified labels and "notifies" on each of those. While this approach works, I doubt it would scale well if everyone is doing this by hand. OTOH, building a service that does this for everyone might be feasible, albeit non-trivial and it's not clear who should own this. So overall having this supported by GitHub would mean a much better UX...

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

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

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

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

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 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

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).

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:

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,

Thank you very much for the feedback! What Chandler said about test-suite totally makes sense to me since it's also excluded from LLVM git monorepo. I will try to land benchmark library to LLVM core repo and update it to the latest version. I have not been doing much CMake/project structure before, but I'll start looking into that next week. I'll reach out to Dominic if anything goes

Hi, as far as I can tell the only mac bot on http://lab.llvm.org:8011/console is http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/37511 which only runs "check-lld". lld is probably the only tool in the LLVM / clang repos that's not widely used on macOS. What happened to the mac bots that run check-clang, check-clang-tools, check-clangd, check-llvm, and so on? Nico

The 2017 LLVM Developers’ Meeting relies on volunteers to keep things running smoothly. Moderators are critical to this as they keep speakers on track and facilitate Q&A after the talk. I’m looking for community members who would be attending specific talks anyway, to volunteer to moderate the session. If you are interested in volunteering, please respond to this email with your first and

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.