Integrated code formatter

H. S. Teoh hsteoh at
Tue Jan 18 01:23:26 UTC 2022

On Mon, Jan 17, 2022 at 05:01:53PM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jan 18, 2022 at 12:40:17AM +0000, forkit via Digitalmars-d wrote:
> [...]
> >
> Alright.  Since you brought it up, I'm gonna try to take a look
> sometime and see if it's simple enough for me to fix.  I'm not very
> familiar with dmd's code, but I *have* fixed a bug or two before so
> I'm gonna take a shot at it.  No guarantees, though! ;-)

OK, first impressions: -profile=gc is a crock.  Not only it fails to
detect GC allocations outside of built-in language constructs, it fails
to create the profilegc.txt output file at all when it detects no
allocations.  I wrote a test program that allocates an array with a
literal, then commented it out to an empty main(), profilegc.txt was NOT
updated. :-/

Honestly, at this point I'd recommend just doing this instead of using
-profile=gc at all:

	import core.memory : GC;

That will tell you the real honest truth of what has actually been
allocated on the GC, straight from the GC horse's mouth. No compiler

I'll take a look at the code now to see if there's anything easily
salvageable...  but at this point I'm ready to propose pulling the
trigger on -profile=gc completely.  (Based on how I suspect it works,
I'm expecting that it would not be easy to implement any useful output
for allocations via druntime functions -- at best you'd just get some
obscure file/line number inside druntime code which would be of no help
locating where in *your* code the allocation happened.)


First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

More information about the Digitalmars-d mailing list