similar to: Proposal for an alternative bugtracking workflow

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,

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

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

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

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

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

Good afternoon. I apologize for my English. Error on page: http://libvirt.org/formatdomain.html To be more precise in the line "<target *def*='hdc' bus='ide'/>" -- Biryukov Alexander ICQ: 467093457 Skype: reddog_gad -------------- next part -------------- An HTML attachment was scrubbed... URL:

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,

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.