SAOC LLDB D integration: 5th Weekly Update
contact at lsferreira.net
Thu Oct 21 20:02:36 UTC 2021
On Thu, 2021-10-21 at 08:46 +0000, WebFreak001 via Digitalmars-d wrote:
> On Thursday, 21 October 2021 at 01:48:32 UTC, Luís Ferreira wrote:
> > Hi D community!
> > [...]
> I love it! Are you planning to do more D related stuff after SAoC
Yes. I have some ideas to improve D ecosystem and also some proposals
in mind for D itself.
- One of the things I'm writing is a DIP to be able to ignore coverage.
The idea is to be able to mark code as not intended to be covered, like
dummy statements. I'm not sure if it is needed a forma DIP, but I'm
doing it anyway to have some rationale.
- Related to coverage I recently created a library/tool to convert
various coverage formats, ready to adapt on a coverage service. I want
to expand it for other well known formats and implement a C API.
- Have a stalled DIP implementation on the compiler about throw STC.
- I'm restructuring the runtime demangler to be faster and exception-
- Have plans to work on a 'silly' package based test runner to support
BetterC and fancy colored diffs with green and red color diffs when
comparing actual and expected sides and syntatic sugar assert
variations for that purpose.
- Have a stale implementation of parser combinators library CTFE ready
to parse protobufs and generically other things more easily.
- I would like to, at some point, contribute to libdparse and dscanner
to implement more code smell and add the possibility of ignoring false
positives or "trust" certain code.
I have planty of other projects that I want to contribute/do but either
my time is limited by other priorities or sometimes not motivated to do
some of them. Normally I do all of them at the same time, and therefore
suffer from the problem of implementing none.
I have my TODO list open-source, so you can check it out:
https://tasks.lsferreira.net/ . I also plan to dramatically improve the
interface of it, and probably D will be involved on that :P
> When I made my LLDB pretty printer plugin I implemented the array
> and string types, which will probably become obsolete once your
> suggested DWARF changes are in the compilers. Additionally if you
> are planning to support D as an LLDB plugin, I think the Phobos
> types would be a great addition in the future (JSONValue,
> Variant, sumtype, DateTime, SysTime, Duration, Appender...) and
> especially if it's somehow possible to detect ranges and evaluate
About that, I think implementing support for array and strings is
straightforward and acceptable, because the memory layout of them are
specified on the D ABI spec. Things like associative arrays and other
data structures are not, and hardcoding the fields is ok but at some
point in time it can break, unfortunetly. I think if we plan to
upstream the plugin too (which I think will not going to happen,
because Rust created a fork due to being denied by the upstream) we
should not include those "ambiguous" additions, although, would be cool
to find another way to export information for the debuggers. If this
end up not being upstreamed, I think we can think about syncing that
with the reference compiler/runtime/stdlib implementation and possibly
support other major implementations. Another possibility is to
standardize the memory layout of those data structures, but I think
that is difficult and restrictive.
But yeah, for now, I'm going to focus on the "achievable" things and
then improve it when I have some "stable" implementation.
Luís Ferreira @ lsferreira.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the Digitalmars-d