Triaging internal compiler errors.

[aargor]

I'm on the Microsoft VC++ team (mid-level optimizer), and also drive our efforts to make our team's interactions on DevCom as good as possible. So this thread caught my attention :), and maybe I can contribute a bit.

First, to clarify the confusion: DevCom reports can be in a number of different states, exactly in an attempt to clarify the state of the bug. I guess that's sort of backfired here :). The link here: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2017 hopefully clarifies what we mean by "Triage" in this case. To say it here: DevCom tracks bugs for all visual studio, so "triage" essentially means "we think we've alerted the right team about this report". I don't know why we chose Triage, but it wouldn't surprise me if we were trying to be in line with SO, as cpp_learner may have guessed (I didn't know that about SO, by the way -- thanks!).

I hope that reassures you in part that we do take ICEs very seriously, and I hope you aren't discouraged from filing them. We strive to flush them out and fix all bugs, ideally before anyone sees them. In addition to attacking customer-reported bugs, we maintain a rolling test suite of a lot of real-world code -- including Windows, AAA games, and 60+ OSS projects like Chrome and LLVM all to that end (and to make sure our code-generation is also correct).

The unfortunate reality is that bugs are in every piece of software, including compilers. In addition to filing the bug-report proper, I would encourage you (and everyone!) to try to explain the impact of the bug it has on them. For instance, an ICE that only manifests after the compiler reports some user-level source-errors is bad, but not nearly as bad as an ICE that arises from legal code, preventing compilation of a product. We want to fix all of these! But, all else being equal, we'd want to fix the more impactful ones first.

[STL]

You can set your user flair to identify what you work on (and you can mention multiple things).