Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] RFC: End-to-end testing
On Fri, 18 Oct 2019 at 16:30, David Greene wrote: > I have been viewing test-suite as a kind of second-level/backup testing > that catches things not flagged by "make check-all." Is that a > reasonable interpretation? I was hoping to get some end-to-end tests > under "make check-all" because that's easier for developers to run in > their workflows. It is a common understanding, which makes the test-suite less useful, but that's not really relevant. No one needs to the test-suite as part of their development processes, because we have bots for that. If you have decent piece-wise tests in Clang/LLVM, you really don't need end-to-end tests in Clang/LLVM, because the test-suite will run on bots and you will be told if you break them. Most errors will be picked up by piece-wise tests, and the minority where e2e make a difference can be reactive, rather than pro-active fixing. > Is there a proposal somewhere of what companies would be expected to do? > It's difficult for us engineers to talk to management without a concrete > set of expectations, resource requirements, etc. There were talks about upgrading Buildbot (the service), moving to Jenkins or something else (Travis?). None of them have the majority of the community behind, and that's the main problem. IIRC, the arguments (definitely outdated, probably wrong) were: Buildbot: - Pros: we already have a big infra based on it, it's passable, an upgrade could ameliorate a lot of problems without creating many new ones. - Cons: it's old tech and requires extensive coding to make it work Jenkins: - Pros: Most companies use that already, it's more modetn than Apple's GreenBot is based on that, lots of plugins and expertise in the community - Cons: It requires Java running on the client, which not all targets like. Alternatives require a separate server to run as a slave and connect to targets. Travis: - Pros: It's natively compatible with Github (is is still the case?) and it could be the easiest to connect with our new repo for CI - Cons: less expertise, I guess, and other things I don't really know. > Nice! That's much better. Yes, it won't scale but it's much clearer > about what is being run. Perhaps adding a new column as to what components we test in each one would be nice. --renato ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Rust support in LLDB, again
> On Oct 17, 2019, at 11:42 PM, Vadim Chugunov wrote:
>
> Hi Greg,
>
> So if Rust doesn't use clang in its compiler
> - create a new TypeSystem for Rust that would convert DWARF into Rust AST
> types that are native to your Rust compiler that uses as much of the Rust
> compiler sources as possible
> - write a native Rust expression parser which hopefully uses your Rust
> compiler sources to evaluate and run your expression
>
> This already exists, but is proving difficult to maintain out-of-tree. (I
> wish that people who modify plugin-related APIs would spend a few minutes
> documenting what each of those methods is supposed to do, so plugin
> maintainers wouldn't need to reverse-engineer this info! /rant).
>
> So the right answer depends on what the Rust community wants. Is the language
> changing rapidly where the debugger must be in sync to take advantage and use
> the latest language features? Or is it stable?
>
> Debug info is mostly stable, but over time there will be changes, of course.
> For example, at some point we'll want to change the symbol mangling scheme.
>
> The other nice things about creating a new TypeSystem, is that it is a plugin
> and you don't need to compile it in. cmake can be taught to conditionally
> compile in your type system if you want it. It would also allow you to have
> more than one Rust type system if needed for different Rust language versions
> that each could be exclusively compiled in. Having your sources be in a new
> TypeSystem plug-in ensure easy merging when it comes to different
> repositories.
>
> Understood. I just want to point out that implementing a complete type
> system plugin just to support one or two type kinds incompatible with C++ is
> a pretty big burden on language implementors.
It definitely is, but I believe that good debugging tools helps people adopt
your language more quickly and if people invested a bit more into the debugging
experience we would have more languages to play with.
> If LLDB had a default "type system" geared towards representing types
> expressible in DWARF, not just those found in the C family, it would be
> usable with other languages without any custom work, at least until one
> starts getting into fancy features like REPL.
> It might also serve as an abstraction layer for supporting different debug
> info formats. As I understand, right now, in order to support MS PDB, we'd
> need to implement a custom parser for it in addition to the DWARF one?
Yeah this is a tough tradeoff as this is what GDB does or at least did the last
time I was working on it. In most debuggers, they make up their own internal
type representation, and have a generic LALR recursive descent parser to
evaluate single expression statements. This parser must work for multiple
languages and problems arise when one language has a keyword or special
operator that others don't have. In the old days, if you wanted to call a C++
function in the GDB expression parser you would need to put quotes around any
qualified names that contained : characters because that had been overloaded by
the expression parser before C++ to allow getting to a static variable in a
file ("g_foo:main.c" or "main.c:g_foo"), So you had to type '"foo::bar"()' in
your expression. The type system tries to avoid these issues by allowing each
language to define the best functionality for each language.
So one route would be to allow your language to use an internal type system
that isn't based on any compiler back end. But that is going to be just as much
work as making a new Rust type system and more problematic to maintain as other
languages jump on board.
>
> Let us know about which approach sounds better to the Rust community and we
> can proceed from there!
>
> I guess we'd prefer to upstream the Rust plugin. But I'm not sure how keep
> it from breaking without requiring all LLVM devs to install a Rust compiler...
One idea is to add rust support in its own TypeSystem and require a cmake
option to manually enable its compilation. If the cmake flag isn't supplied,
Rust is not compiled in by default. That way you can upstream it, people can
try to enable it if any only if they download the rust compiler sources. Might
be nice to have a rust compiler revision or hash that people can/should
checkout that is documented in the checked out LLDB sources in the Rust type
system README. This revision would be the last known good revision of the Rust
compiler sources they should download in order to build the version of Rust
that is in LLDB's sources. This way it would not break if we had a script in
the Rust LLDB sources that knew how to checkout the right version of Rust and
then users can manually enable Rust. Any rust enabled buildbots could ensure
the right Rust sources are checked out. Maybe you could integrate this with the
LLVM mono repo where Rust could be a module that can be added so when you add
the
