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 use
I think it's a "Cross that bridge when we come to it"
See if manual enforcement is sufficient - if it becomes a real problem
that's too annoying to handle manually/culturally, then assess what sort of
automation/enforcement seems appropriate for the situation we are in at
that time.
On Thu, Oct 1
On Thu, 17 Oct 2019 at 18:10, David Greene wrote:
> From other discussion, it sounds like at least some people are open to
> asm tests under clang. I think that should be fine. But there are
> probably other kinds of end-to-end tests that should not live under
> clang.
That is my position as we
https://bugs.llvm.org/show_bug.cgi?id=43707
Bug ID: 43707
Summary: Constructing objects in expressions doesn't work on
Windows
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Statu
On Thu, Oct 17, 2019 at 11:17 AM Philip Reames via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> I'm also a strong proponent of not requiring the wrapper.
>
> The linear history piece was important enough to make the cost worth it.
> The extra branches piece really isn't. If someone creates a bran
I'm also a strong proponent of not requiring the wrapper.
The linear history piece was important enough to make the cost worth
it. The extra branches piece really isn't. If someone creates a branch
that's not supposed to exist, we just delete it. No big deal. It will
happen, but the cost is
> On Sep 28, 2019, at 4:00 PM, Vadim Chugunov via lldb-dev
> wrote:
>
> Hi,
> Last year there was an effort led by Tom Tromey to add Rust language support
> into LLDB. He had implemented a fairly complete language plugin, however it
> was not accepted into mainline because of supportability
The only thing I can think if is stdin/out/err are not setup correctly when
launched out of the debugger. How does your program get launched? From a
terminal on the command line?
printf will call fprintf() under the covers with stdout as the file handle.
Maybe "stdout" can be checked for NULL w
https://bugs.llvm.org/show_bug.cgi?id=43702
Bug ID: 43702
Summary: platform process list -v doesn't show all processes on
Windows.
Product: lldb
Version: 9.0
Hardware: PC
OS: Windows NT
Status: N
On Thu, 17 Oct 2019 at 16:28, Robinson, Paul wrote:
> This is no different than today. Many tests in Clang require a specific
> target to exist. Grep clang/test for "registered-target" for example;
> I get 577 hits. Integration tests (here called "end-to-end" tests)
> clearly need to specify thei
On 10/17/19 10:00 AM, David Greene via cfe-dev wrote:
> Mehdi AMINI via llvm-dev writes:
>
>> The main thing I see that will justify push-back on such test is the
>> maintenance: you need to convince everyone that every component in LLVM
>> must also maintain (update, fix, etc.) the tests that ar
Renato wrote:
> If you want to do the test in Clang all the way to asm, you need to
> make sure the back-end is built. Clang is not always build with all
> back-ends, possibly even none.
This is no different than today. Many tests in Clang require a specific
target to exist. Grep clang/test for "r
Mehdi AMINI via llvm-dev writes:
> The main thing I see that will justify push-back on such test is the
> maintenance: you need to convince everyone that every component in LLVM
> must also maintain (update, fix, etc.) the tests that are in other
> components (clang, flang, other future subprojec
David Blaikie via llvm-dev writes:
> & I generally agree that end-to-end testing should be very limited - but
> there are already some end-to-end-ish tests in clang and I don't think
> they're entirely wrong there. I don't know much about the vectorization
> tests - but any test that requires a t
Hi,
At the upcoming LLVM Dev Conf, we will have a round table discussion for
ASTImporter, right after the ASTImporter Tutorial.
The time slot for the round table is Wednesday, Oct 23 2:55-4:00.
I have gathered things about possible future work and improvements, bring
your own topic to discuss!
Th
On Wed, 16 Oct 2019 at 21:00, David Greene wrote:
> Can you elaborate? I'm talking about very small tests targeted to
> generate a specific instruction or small number of instructions.
> Vectorization isn't the best example. Something like verifying FMA
> generation is a better example.
To chec
16 matches
Mail list logo
