Is it possible to change the keyword descriptions?
I would like:
xfail  - "Obsolete - Don't use this"
ice-on-invalid-code  - "Obsolete - Don't use this"
ice-on-valid-code   "Internal compiler error (assert failure,
segfault, or stack overflow)"

The reason being, that in almost all case, invalid code is valid is
some context, so there's really no difference between ice-on-valid and
ice-on-invalid, and people get confused about which one to use.
(ideally, change all ice-on-invalid to ice-on-valid, remove
ice-on-invalid completely, and rename ice-on-valid as simply "ice" --
but simply changing the description would be an improvement).
xfail comes from dstress and has never been used.

Extra keywords that could be added:
inliner     bug appears only if -inline is used
optimizer  bug appears only with -O
line-number  error message with incorrect or missing line number
parser   bug occurs in lexing or parsing step
64bit    bug shows different behavior on 64bit vs 32bit

Yes please.  I wouldn't mind seeing the D version options reduced to D1/D2/D1 and D2, or a bunch of new keywords.  Anything that is currently done with description prefixes or tracker bugs would my much easier to use if it was a keyword.

Eg. ctfe, module, template, contracts, safed, purity, const/immutable, auto etc If they were there, I'd use them.

On Tue, Jan 31, 2012 at 10:54 PM, Don Clugston <dclugston at googlemail.com> wrote:
> Is it possible to change the keyword descriptions?
> I would like:
> xfail ?- "Obsolete - Don't use this"
> ice-on-invalid-code ?- "Obsolete - Don't use this"
> ice-on-valid-code ? "Internal compiler error (assert failure,
> segfault, or stack overflow)"
>
> The reason being, that in almost all case, invalid code is valid is
> some context, so there's really no difference between ice-on-valid and
> ice-on-invalid, and people get confused about which one to use.
> (ideally, change all ice-on-invalid to ice-on-valid, remove
> ice-on-invalid completely, and rename ice-on-valid as simply "ice" --
> but simply changing the description would be an improvement).
> xfail comes from dstress and has never been used.
>
> Extra keywords that could be added:
> inliner ? ? bug appears only if -inline is used
> optimizer ?bug appears only with -O
> line-number ?error message with incorrect or missing line number
> parser ? bug occurs in lexing or parsing step
> 64bit ? ?bug shows different behavior on 64bit vs 32bit
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 1/31/2012 3:54 AM, Don Clugston wrote:
> Is it possible to change the keyword descriptions?
> I would like:
> xfail  - "Obsolete - Don't use this"
> ice-on-invalid-code  - "Obsolete - Don't use this"
> ice-on-valid-code   "Internal compiler error (assert failure,
> segfault, or stack overflow)"

xfail is unused and should just be deleted, I'll do that.

phobos is unused and is redundant to the product category, and so should be deleted. I'll do that.

ice-on-* should all be merged into "ice", which should include all compiler internal errors and seg faults. I'll add ice.

I'd like to be parsimonious about just creating a bunch of new keywords. I've added a couple, but only because I wanted to work on a particular aspect.

> The reason being, that in almost all case, invalid code is valid is
> some context, so there's really no difference between ice-on-valid and
> ice-on-invalid, and people get confused about which one to use.
> (ideally, change all ice-on-invalid to ice-on-valid, remove
> ice-on-invalid completely, and rename ice-on-valid as simply "ice" --
> but simply changing the description would be an improvement).
> xfail comes from dstress and has never been used.
>
> Extra keywords that could be added:
> inliner     bug appears only if -inline is used
> optimizer  bug appears only with -O
> line-number  error message with incorrect or missing line number
> parser   bug occurs in lexing or parsing step
> 64bit    bug shows different behavior on 64bit vs 32bit
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>

Here's the list:

http://d.puremagic.com/issues/editkeywords.cgi

On 1/31/2012 3:54 AM, Don Clugston wrote:
> Is it possible to change the keyword descriptions?
> I would like:
> xfail  - "Obsolete - Don't use this"
> ice-on-invalid-code  - "Obsolete - Don't use this"
> ice-on-valid-code   "Internal compiler error (assert failure,
> segfault, or stack overflow)"
>
> The reason being, that in almost all case, invalid code is valid is
> some context, so there's really no difference between ice-on-valid and
> ice-on-invalid, and people get confused about which one to use.
> (ideally, change all ice-on-invalid to ice-on-valid, remove
> ice-on-invalid completely, and rename ice-on-valid as simply "ice" --
> but simply changing the description would be an improvement).
> xfail comes from dstress and has never been used.
>
> Extra keywords that could be added:
> inliner     bug appears only if -inline is used
> optimizer  bug appears only with -O
> line-number  error message with incorrect or missing line number
> parser   bug occurs in lexing or parsing step
> 64bit    bug shows different behavior on 64bit vs 32bit
>

On 31 January 2012 20:21, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 1/31/2012 3:54 AM, Don Clugston wrote:
>>
>> Is it possible to change the keyword descriptions?
>> I would like:
>> xfail ?- "Obsolete - Don't use this"
>> ice-on-invalid-code ?- "Obsolete - Don't use this"
>> ice-on-valid-code ? "Internal compiler error (assert failure,
>> segfault, or stack overflow)"
>
>
> xfail is unused and should just be deleted, I'll do that.
>
> phobos is unused and is redundant to the product category, and so should be deleted. I'll do that.
>
> ice-on-* should all be merged into "ice", which should include all compiler internal errors and seg faults. I'll add ice.
>
> I'd like to be parsimonious about just creating a bunch of new keywords. I've added a couple, but only because I wanted to work on a particular aspect.

Fair enough. Actually, with regard to keywords, the biggest potential
improvement involves patches. There's over 1000 of them, and nearly
200 are open, so it's the second biggest category.
At the moment, many bugs are listed as 'patch' even though the patch
is known to be incomplete or incorrect. Which is unhelpful and looks
bad.
We should either remove the patch keyword from those bugs, or create a
new keyword like 'partial-patch' or 'rejected-patch' for that
situation, depending on whether we think it's worth tracking them.

On 1/31/2012 11:51 AM, Don Clugston wrote:
>
> Fair enough. Actually, with regard to keywords, the biggest potential
> improvement involves patches. There's over 1000 of them, and nearly
> 200 are open, so it's the second biggest category.
> At the moment, many bugs are listed as 'patch' even though the patch
> is known to be incomplete or incorrect. Which is unhelpful and looks
> bad.
> We should either remove the patch keyword from those bugs, or create a
> new keyword like 'partial-patch' or 'rejected-patch' for that
> situation, depending on whether we think it's worth tracking them.
>

I suggest removing the patch keyword for those patches which are known to not be correct fixes. Such patches really only serve as additional information that may be helpful for anyone trying to fix it correctly.

For the good patches, I'd like to see them redone as pull requests.

For issues with pull requests fixing them, perhaps adding a 'pull' keyword will be appropriate.

I'm not sure what the disadvantage of having a bunch of new keywords is, worst case they never get used.

Best case they make related bugs much easier to search for.  People are much better at assigning keywords than they are at giving bugs meaningful and searchable descriptions.  A lot of the time to find duplicates I have to rely on my memory and searching for synonyms.

As for pull requests, it seems like they could be better represented
by a status change. (I don't know how customizable bugzilla is here)
Something like NEW -> CONFIRMED -> ASSIGNED -> PATCHED -> (MERGED) -> FIXED
This would better document the actual life cycles of the bugs.

Something to consider.  The current setup is workable but it could be a little better.

On Wed, Feb 1, 2012 at 8:15 AM, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 1/31/2012 11:51 AM, Don Clugston wrote:
>>
>>
>> Fair enough. Actually, with regard to keywords, the biggest potential
>> improvement involves patches. There's over 1000 of them, and nearly
>> 200 are open, so it's the second biggest category.
>> At the moment, many bugs are listed as 'patch' even though the patch
>> is known to be incomplete or incorrect. Which is unhelpful and looks
>> bad.
>> We should either remove the patch keyword from those bugs, or create a
>> new keyword like 'partial-patch' or 'rejected-patch' for that
>> situation, depending on whether we think it's worth tracking them.
>>
>
> I suggest removing the patch keyword for those patches which are known to not be correct fixes. Such patches really only serve as additional information that may be helpful for anyone trying to fix it correctly.
>
> For the good patches, I'd like to see them redone as pull requests.
>
> For issues with pull requests fixing them, perhaps adding a 'pull' keyword will be appropriate.
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals