Re: [Lldb-commits] Prevent type canonization when dereferencing

Hi Lasse, the test from the patch passes for me even without your non-test changes. Not sure if you attached the wrong diff or it needs to be applied on a specific commit that is not ToT? Can you maybe try pushing your code to some git repo? Your change to TypeSystemClang (which I assume remove

Re: [Lldb-commits] Prevent type canonization when dereferencing

I assume your bug is for dereferencing references? In your test taking the ref variable and then dereferencing it via the SB API reproduces that I think you're running into: >>> lldb.frame.FindVariable("p_ref").GetType().GetName() 'TPair &' >>> lldb.frame.FindVariable("p_ref").Dereference().GetT

Re: [Lldb-commits] Prevent type canonization when dereferencing

Thanks1 fixed here: https://reviews.llvm.org/D103532 > On 2 Jun 2021, at 18:06, Andy Yankovsky wrote: > > I think the problem is specific to references, at least that's the case I ran > into in lldb-eval -- > https://github.com/google/lldb-eval/blob/master/docs/lldb-bugs.md#dereferencing-a-val

Re: [Lldb-commits] [PATCH] D74475: [lldb] Replace assertTrue(a == b, "msg") with assertEquals(a, b, "msg") in the test suite

Thanks, I thought I fixed that before committing (that was the one change that Pavel missed IIRC). > On 14. Feb 2020, at 07:53, Jonas Devlieghere via Phabricator > wrote: > > JDevlieghere added a comment. > > Yup, looks like that was it, the bot is green again: > http://lab.llvm.org:8011/bui

Re: [Lldb-commits] [PATCH] D74556: [lldb] Don't call CopyForBreakpoint from a Breakpoint's constructor

I assume this is causing the test to fail on Windows? http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/13896 > On 18. Feb 2020, at 12:26, Tatyana Krasnukha via Phabricator > wrote: > > tatyana-krasnukha closed this revision. > tatyana-krasnukha added a comment. > > Closed by co

Re: [Lldb-commits] [PATCH] D74556: [lldb] Don't call CopyForBreakpoint from a Breakpoint's constructor

Thanks! > On Feb 18, 2020, at 1:24 PM, Tatyana Krasnukha > wrote: > > The test was passing unexpectedly, I already removed XFAIL decorator. > > -Original Message- > From: Raphael “Teemperor” Isemann > Sent: Tuesday, February 18, 2020 3:20 PM > To: reviews+d74556+public+411e87b2a9392.

Re: [Lldb-commits] [lldb] b6b3fcd - [lldb] Don't iterate over a std::set in SymbolFileDWARF::GetTypes to make it deterministic

I was just grepping for unordered data structures (e.g. ’std::set<‘) that use pointers/pointer-like objects (e.g. CompilerType with its operator<) and then reading the related code. Not sure if there is a good way to detect this stuff automatically. I guess we could have had a Clang plugin that

Re: [Lldb-commits] [lldb] e98ef0a - [lldb] Fix several LLDB_LOGs with wrong indices in ClangASTSource.cpp

Yeah this whole thing is a disaster and it’s puzzling that we don’t test the whole logging but instead just crash on the end user machine. I’m currently writing a test that gives all this code at least coverage and then I guess we have to fix all of these bugs. > On Mar 4, 2020, at 10:53 AM, Sh

Re: [Lldb-commits] [lldb] 4b074b4 - [lldb] Fix UB in half2float and add some more tests.

I think what you're looking for is llvm::bit_cast (in ADT/bit.h) :) But that code was written before that, so that's why it's still using unions > On 19 May 2021, at 23:27, Shafik Yaghmour wrote: > > *sigh*I wish we had std::bit_cast instead of using union based type punning, > we do have __bu

Re: [Lldb-commits] [lldb] 074b121 - Reland [lldb] Unify type name matching in FormattersContainer

That's actually a better idea. Relanded it with the member removed and constructor deleted. Thanks! - Raphael > On 23 Jul 2020, at 09:49, Eric Christopher wrote: > > Hi Raphael, > > I've temporarily reverted this again with hopefully a better explanation here: > > echristo@athyra ~/s/llvm-pr

Re: [Lldb-commits] [lldb] 0d5fc82 - [lldb] Eliminate unneeded value parameters in Utility (NFC)

We could make a custom attribute for types that should be always passed by value and then maybe have Clang handle that. The problem seems generic enough that maybe other people could find this useful. - Raphael > On 24 Jul 2020, at 09:27, Pavel Labath via lldb-commits > wrote: > > On 23/07/2

Re: [Lldb-commits] [lldb] a06c28d - Temporarily revert "[test] Exit with an error if no tests are run."

If it helps, all the failing tests are pexpect tests which are always disabled on Windows (like, they don't even exist from the test runners POV I believe). So I guess that's accidentially triggering that error. - Raphael > On 4 Aug 2020, at 03:39, Jordan Rupprecht via lldb-commits > wrote: >

Re: [Lldb-commits] [lldb] f369d51 - [lldb] avoid assert in threadsanitizer tests on linux

I already fixed that bug on Monday, so this is now just assigning a second fallback value. See https://reviews.llvm.org/D86593 Cheers, - Raphael > On 3 Sep 2020, at 21:18, Luboš Luňák via lldb-commits > wrote: > > > Author: Luboš Luňák > Date: 2020-09-03T21:18:17+02:00 > New Revision: f369d

Re: [Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

+1, I have two machines with very similar setup where only the one that is under heavy load sees the test failures. - Raphael > On 1 Oct 2020, at 14:24, Pavel Labath wrote: > > On 30/09/2020 23:21, Jim Ingham wrote: >> The test doesn’t seem to be flakey in the “run it a bunch of times and >> i

Re: [Lldb-commits] [PATCH] D68597: Replace static const StringRef with StringRef (NFC)

We actually call the libc++abi guard functions even for const static StringRefs, so that patch actually saves us a lot. > On Oct 7, 2019, at 11:43 PM, Adrian Prantl via Phabricator via lldb-commits > wrote: > > aprantl created this revision. > aprantl added a reviewer: JDevlieghere. > > I jus

Re: [Lldb-commits] [lldb] r367385 - [CompletionRequest] Remove unimplemented members.

Thanks! Wasn’t sure back then if I can just remove that weird thing > On Jul 31, 2019, at 5:48 AM, Jonas Devlieghere via lldb-commits > wrote: > > Author: jdevlieghere > Date: Tue Jul 30 20:48:29 2019 > New Revision: 367385 > > URL: http://llvm.org/viewvc/llvm-project?rev=367385&view=rev > Log

Re: [Lldb-commits] [lldb] r369506 - [lldb][NFC] Add tests for invalid command invocations

Thanks, just pushed a fix where I merge that into the dedicated apropos test! > On 21. Aug 2019, at 16:16, Pavel Labath wrote: > > On 21/08/2019 11:15, Raphael Isemann via lldb-commits wrote: >> Author: teemperor >> Date: Wed Aug 21 02:15:44 2019 >> New Revision: 369506 >> URL: http://llvm.org/v

Re: [Lldb-commits] [lldb] r369652 - [lldb][NFC] Fix indentation in CommandObjectProcess

Fix is already committed as 369660, sorry for that. - Raphael > On Aug 22, 2019, at 5:28 PM, Alexander Kornienko via lldb-commits > wrote: > > This commit breaks buildbots: > http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/8107 >

Re: [Lldb-commits] [lldb] r364967 - [lldb] Mention automatic codesign setup script [NFC]

Yeah that whole document should probably be part of the build section for macOS. I can move the guide there because I anyway have to learn how the new website works :) - Raphael > On Jul 2, 2019, at 3:27 PM, Jonas Devlieghere wrote: > > Should we convert this to RST file and make it a proper

Re: [Lldb-commits] [PATCH] D92759: [lldb] Introduce separate scratch ASTs for debug info types and types imported from C++ modules.

Yeah, that's an unfortunate bug in GCC 5.x. I actually just fixed that before the weekend in https://reviews.llvm.org/rG37510f69b4cb8d76064f108d57bebe95984a23ae +CC Tom (who is the release manager AFAIK), as that commit prob

Re: [Lldb-commits] [PATCH] D80308: [lldb] Enable C++14 when evaluating expressions in a C++14 frame

Sorry, somehow I missed that mail. Reverted. > On 22. May 2020, at 21:20, Max Kudryavtsev via Phabricator > wrote: > > max-kudr added a comment. > > Hello, > > I suppose this commit broke Windows LLDB tests > (http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/16486 -> > logs:

Re: [Lldb-commits] [lldb] 90c1af1 - [lldb][NFC] Add more test for builtin formats

Sorry for that, it seems I overlooked those failure mails. Thanks! > On 20 Jun 2020, at 23:22, Eric Christopher wrote: > > This is failing on some of the debian buildbots so I've temporarily reverted > it here: > > commit 10b43541360efb35a1d33e9cf1e93023ebd69b15 (HEAD -> master, > origin/mast

Re: [Lldb-commits] [lldb] 7d175cf - [lldb] Xfail TestCallOverriddenMethod.py for aarch64/linux

Can you share the error output of the test failure? > On 9. Dec 2019, at 12:38, Muhammad Omair Javaid via lldb-commits > wrote: > > > Author: Muhammad Omair Javaid > Date: 2019-12-09T16:38:33+05:00 > New Revision: 7d175cf504bceb72a487a83ed9f640011832d46d > > URL: > https://github.com/llvm/ll

Re: [Lldb-commits] [lldb] 22caa3c - [lldb] Add unit test for ClangASTImporter

I’m actually already investigating that because I see the same failure when I moved the ::Initialize and ::Terminate calls to SetUp and TearDown as part of D71630. I’ll reply here when I have a fix, thanks! > On Dec 18, 2019, at 10:54 PM, Jordan Rupprecht wrote: > > We're seeing some odd test

Re: [Lldb-commits] [lldb] 22caa3c - [lldb] Add unit test for ClangASTImporter

Fixed by https://reviews.llvm.org/D71748. Will land this today. > On 18. Dec 2019, at 23:03, Raphael “Teemperor” Isemann > wrote: > > I’m actually already investigating that because I see the same failure when I > moved the ::Initialize and ::Terminate calls to SetUp and TearDown as part of >

Re: [Lldb-commits] [lldb] fe8e25a - [lldb][NFC] Create type-safe function for creating a CompilerType from a QualType

Somehow your mail is missing examples after the ‘… like:’ but the method is named similar to the GetType* methods directly below it. Don’t really have an opinion about whether this should be GetType* or GetCompilerType* (though I wouldn’t add the ‘As’ to it though as that’s usually used for cast

Re: [Lldb-commits] [lldb] 8612e92 - [lldb][NFC] Remove GetASTContext call in ClangDeclVendor

Not sure if I can follow. What variable should just be a Decl* and what operator On Jan 3, 2020, at 12:38 AM, Shafik Yaghmour wrote: > > I am not crazy about the reinterpret_cast although if we look inside > CompilerDecl impl we can see that basically it is always assuming it is a > Decl* and

Re: [Lldb-commits] [lldb] 8612e92 - [lldb][NFC] Remove GetASTContext call in ClangDeclVendor

We could use clang::Decl* etc. in these classes but that would defeat the whole concept that they are supposed to implement. CompilerType, CompilerDecl, etc.. are all classes that represent their respective equivalent in a language plugin. For Clang that is indeed clang::Type* and clang::Decl*,