January 18, 2022
On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright wrote:
> On 1/17/2022 6:06 PM, deadalnix wrote:
>> Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.
>
> What comes to mind is what to do with the comments.

They must be kept, which is what dfmt does as it follows the token stream and *not* the AST.
January 18, 2022
On Monday, 17 January 2022 at 23:42:50 UTC, forkit wrote:

>
> But to have bugs sit their for 7 years, not discussed, not addressed in any way.. then.. from where does one get the motivation to file a new bug?

Razvan Nitu was hired as a PR/Issue manager last year precisely to bring some method to our bug fixing madness. Prior to that, bugs were fixed by anyone who took an interest in them. If no one did, they didn't get fixed.

In the year+ since he took on the role, Razvan has assembled strike teams for the major repositories. Together, they have trimmed the PR queues and begun to make a dent on the Bugzilla database.

There are still old issues there, yes, and many of them will still remain there for quite a while longer. It takes time to go through such a big backlog. But new issues have a better chance of getting fixed sooner now.  The second PR/Issue manager position is being filled soon, which will bring another pair of paid eyes and hands to bear on Bugzilla.

That said, some issues will still linger because there isn't an obvious way to fix them, or they're judged a lower priority, or for whatever reason. They may be forgotten. Posting about a specific issue here in the forums is one way to do bring attention to it. Another is to tweet about it with the #dlang hashtag. Anytime I see something like that, I email Razvan about it to see if he can do something about it or find someone who can. Usually, they get closed in a few days.

My point: issues that aren't reported aren't fixed, and those that are reported have a better chance of getting fixed sooner these days than they used to.

I've never believed that "it might stay there for 7 years" is a valid reason to avoid reporting a bug, but it's even less so now.

Please report your issues. And if they aren't fixed in a reasonable amount of time, shout about them to bring attention to them. Even with the increase in manpower Symmetry's sponsorship has brought us, D is still a community effort. Reporting an issue, then reminding people it's there, is one of the simplest ways to contribute to that effort.
January 18, 2022
Although many have proposed it, we don't delete bugzilla issues just because they are old.

> issues that aren't reported aren't fixed

I want the emphasize that. Many times, people say this or that bug is not fixed. I ask if it is in bugzilla, they say no. This is even from longtime community members.

Reporting bugs on the forums doesn't work, unless it is *also* reported on bugzilla.

It's got to go into bugzilla.

For example, not too long ago, there were some major frustrations posted about the compiler's bad error messages. No examples were given, and no bugzilla entries had been posted. There's nothing anyone who wants to help can do about that.
January 18, 2022
On Tuesday, 18 January 2022 at 08:42:17 UTC, Mike Parker wrote:
>
> I've never believed that "it might stay there for 7 years" is a valid reason to avoid reporting a bug, but it's even less so now.
>
> Please report your issues. And if they aren't fixed in a reasonable amount of time, shout about them to bring attention to them. Even with the increase in manpower Symmetry's sponsorship has brought us, D is still a community effort. Reporting an issue, then reminding people it's there, is one of the simplest ways to contribute to that effort.

Well it's not that it 'might' stay there for 7 years, it's that it 'has' stayed there for 7 years:

https://issues.dlang.org/show_bug.cgi?id=14892

I'd just be reporting the same thing... so not much point.

I got know idea whatsoever on how to fix it. If I did, I'd do it.

The best I could work out, was how to add a warning into the header of the profilegc.log stating how completely useless it is ;-)

My real point, is that -profile=gc seems like such a useful tool...how could it not get anyones attention, after 7 years??

I presume nobody uses it, because they know about this issue ??

But as soon as newcomers arrive, use it, expecting it to what it says it does, they soom fine out it's completely useless too, and everyone has known for 7 years...so now the newcomer stops using it.. ... and then the next newcomer comes along... and....

btw. @nogc is not an alternative as some have suggested.

January 18, 2022
On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright wrote:
> On 1/17/2022 6:06 PM, deadalnix wrote:
>> Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.
>
> What comes to mind is what to do with the comments.

Yes, this is the most obvious ones, but then you have, what to do with whitespaces? There is a ton of semantic conveyed in whitespace, for instance, one new line or two new lines? It gets worse when you want to add features such as "don't format that specific chunk of code" because now you need ot be able to encode EVERYTHING in the AST, and it gets very teddious.
January 18, 2022
On Tuesday, 18 January 2022 at 05:47:29 UTC, H. S. Teoh wrote:
> On Mon, Jan 17, 2022 at 07:30:53PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 1/17/2022 6:06 PM, deadalnix wrote:
>> > Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.
>> 
>> What comes to mind is what to do with the comments.
>
> They should be explicitly represented. Ignored by the part that deals with language grammar, but remain in place to be accounted for during formatting.
>
>
> T

Yes, but it's not that simple. See for instance.

int a; // This is an int.
int b;

vs

int a;
// This is an int.
int b;

We understand the comment to be attached to a in the first case, while we understand it is attached to b in the second.
January 18, 2022
On Tuesday, 18 January 2022 at 08:36:18 UTC, user1234 wrote:
> On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright wrote:
>> On 1/17/2022 6:06 PM, deadalnix wrote:
>>> Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.
>>
>> What comes to mind is what to do with the comments.
>
> They must be kept, which is what dfmt does as it follows the token stream and *not* the AST.

See https://forum.dlang.org/post/givmbzmvnjnweozrexgm@forum.dlang.org
January 18, 2022
On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:
> For example, not too long ago, there were some major frustrations posted about the compiler's bad error messages. No examples were given, and no bugzilla entries had been posted. There's nothing anyone who wants to help can do about that.

If you actually used D for any real work, you wouldn't need a bugzilla issue to know the error messages are really bad.
January 18, 2022
On Tuesday, 18 January 2022 at 12:58:17 UTC, Adam D Ruppe wrote:
> On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:
>> For example, not too long ago, there were some major frustrations posted about the compiler's bad error messages. No examples were given, and no bugzilla entries had been posted. There's nothing anyone who wants to help can do about that.
>
> If you actually used D for any real work, you wouldn't need a bugzilla issue to know the error messages are really bad.

Walter: Please file bug reports about bad error messages so that they can get improved
Forum: But error messages are so bad.
Repeat
January 18, 2022
On Tuesday, 18 January 2022 at 12:58:17 UTC, Adam D Ruppe wrote:
> On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:
>> For example, not too long ago, there were some major frustrations posted about the compiler's bad error messages. No examples were given, and no bugzilla entries had been posted. There's nothing anyone who wants to help can do about that.
>
> If you actually used D for any real work, you wouldn't need a bugzilla issue to know the error messages are really bad.

I'm inclined to say there's a lower standard for error messages if you're the one that wrote the compiler.