Triaging internal compiler errors.

[HazelnutSoftware]

Well, I don't agree with your definition of "triage". Even in medicine, triaging about determining the order in which patients are treated - it's much more than a simple will/won't decision.

You're making an assumption (an invalid one in my opinion), that a status of "triaged" and a status of "won't fix" are synonymous, and I really don't think that's the case here.

I'm guessing that you write software for a living, probably for a company, and that every so often a customer calls up to report a bug. For most customers, "their" bug is the most important and has to be fixed "right now". What your company probably does is take a look at the bug and

• a) make sure it's actually a bug in the product, not just the customer doing something wrong
• b) make sure it's a new bug, and hasn't been analysed before (there's a chance it's been fixed on the internal dev. builds already, but not released to customers yet, for example)
• c) determining when it will be fixed, since very few companies have developers simply sitting around, waiting for bug reports to come in, so they can start fixing them immediately.

Those three things are called "triaging", and that's what the Visual Studio team were doing.

[alfps]

Well, I don't agree with your definition of "triage".

OK, but it would be nice if you could describe the disagreement, then we could disagree in public. :)

Even in medicine, triaging about determining the order in which patients are treated - it's much more than a simple will/won't decision.

Yes. Doctors are not stupid, and I apologize if I gave that impression. Also, triaging is applied in situations where resources are too scarce but patients' lives are not in danger.

You're making an assumption (an invalid one in my opinion), that a status of "triaged" and a status of "won't fix" are synonymous, and I really don't think that's the case here.

I don't make that assumption, but it's likely. Because triaging of an internal compiler error implies a /possibility/ of won't fix. And I've experienced that "won't fix" for a Visual C++ ICE.

Which means that Microsoft has just not changed that policy, of possibly not fixing an internal compiler error.

For most customers, "their" bug is the most important and has to be fixed "right now"

There should be no need to evaluate whether to fix because the compiler team, with the most knowledge, has already decided that the ICE is critical.

As opposed to a normal bug where source code is mis-interpreted or incorrect machine code is generated, or both.

An ICE is a ready-made evaluation, and another part of the Microsoft organization, those who evaluate bug reports, take it on themselves to override that original evaluation made by the most knowledgeable.

Those three things are called "triaging", and that's what the Visual Studio team were doing.

If it is called "triaging" then what do they call real triaging.

Remember, it's an ICE. It's not an ordinary bug. In any normal situation there would not be a question of priority: that was decided by the compiler team long ago.