- User Since
- Mar 23 2016, 8:38 AM (365 w, 2 d)
Feb 14 2023
- Address builtin redefining (Thanks Michael!)
Dec 9 2022
Nov 18 2022
Aug 12 2022
Jul 20 2022
import-std-module test changes look good to me, thanks for fixing that up.
Jun 30 2022
Jun 13 2022
I don't really have the full context here, but I am wondering if we shouldn't somehow take the DW_AT_declaration attribute into account here. It seems like that should give a more definitive answer as to whether we can expect to see a full set of template parameters or not.
May 20 2022
Don't have access to a macOS machine that can run the tests, so maybe someone should give this a spin before landing :)
Apr 7 2022
This is beautiful
Mar 24 2022
Thanks, reverting while investigating.
Mar 6 2022
LGTM, thanks! FWIW, if you have fish installed you might wanna check what they are doing on your terminal for its autosuggestions (and we might wanna steal their default, even though I thought this was 'faint').
Feb 24 2022
Just some drive-by comments, but in general I think this would be nice to get fixed.
Jan 19 2022
I'm really sorry @martong , but I no longer work on LLDB (or the ASTImporter) and I'm not really in the loop regarding LLDB development.
Dec 5 2021
Btw, that patch that I referenced hasn't landed yet (it just lacks the tests and probably rebasing), but I'm OOO for an unknown duration so feel free to land it yourself.
Nov 24 2021
LGTM, thanks for fixing this!
Nov 17 2021
Nov 13 2021
Nov 12 2021
- Update from git
@labath raised some concerns in IRC about the setup code being run in a potential multithreaded env (which makes sense). Feel free to revert (not sure when/if I'll get around to address the issues)
Nov 11 2021
Thanks a lot for fixing this, could you point to D103532 as the cause for the regression in the commit message?
I really like the solution, but I think by fixing the CanInterpret you also made the test case no longer reach the actual changed interpreting logic?
Are you asking for dedicated physical resources for running nightly builds?
Are the DWARFASTParserClang changes meant as a step towards making it parse D?
I changed the commit name from "Add support for D programming language" to "[lldb] Add support for demangling D symbols" when landing (which is more accurate).
Nov 10 2021
I guess that's just clang-format ran over the file? If yes, then LGTM
I actually didn't see that the patch deleted the TestCppReferenceToOuterClass test. Could you just add a @skipIf # Crashes or so above its def test... method? The test itself is still valid user code that we shouldn't crash on.
- Clang-format some last minute renames
I'm pretty sure you're trying to solve the same problem as here: D85993
Nov 9 2021
Note that the changed Dump method and the dump method that takes an ExecutionContext are not tested as we can't test those things via unit tests. They can only be tested with an updated DWARF parser on a real executable/process.
LGTM, thanks for this!
Nov 5 2021
0xffffffff still seems to randomly find __NSCFNumber according to Green Dragon (and the same happens locally with an about 10% chance).
Nov 4 2021
Nov 3 2021
Nov 2 2021
I think this was just fixed by 48677f58b06cfb8715902173c5bc3d1764d7c8c6
Nov 1 2021
Small note: gmodules test are never run on Linux, so you actually have to run them on macOS (or I think FreeBSD) to know whether the tests work.
Oct 31 2021
Oct 30 2021
Oct 29 2021