Integrated code formatter

[H. S. Teoh]

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:
> [...]
> > https://issues.dlang.org/show_bug.cgi?id=14892
> 
> 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;
	writeln(GC.stats);

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
lies.

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.)


T

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