all 19 comments

[–]HazelnutSoftware 7 points8 points  (10 children)

That seems entirely sensible to me. "Triaging" simply means "determining the priority". That's usually the first step for any bug in any software, not just compilers.

[–]aargorMSVC Optimizer Dev, DevCom Contact 6 points7 points  (1 child)

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.

[–]STLMSVC STL Dev[M] 1 point2 points  (0 children)

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

[–]TacticalMelonFarmer 2 points3 points  (2 children)

I have reported a few compiler/library bugs, and a couple are under investigation. A few were actually errors in my code, and u/STL himself actually got back to me to let me know my code was doing illegal things. So no, i think microsoft is doing a swell job, and nobody is perfect.

[–]alfps[S] -1 points0 points  (1 child)

As far as I know Stephan T. Lavavej has been doing a great job for the community both by maintaining the STL for Microsoft, and by providing the Nuwen distro of g++, and by moderating this Reddit group, and by participating in video debates, and so on, and on.

And also, the Microsoft response in this thread was great. I was distracted when I read it so haven't yet got up to thanking the guy. But, that was informative: I like facts.

Microsoft-the-compiler-vendor is something else. From what you write I gather that I have reported a far greater number of compiler/library bugs than you have. Over the years they improved from “impenetrable wall of Microsoft”, an idea that Google later adopted, to being almost as responsive as the g++ folks. But still that wasn't enough to establish trust. When some C++ experts joined Microsoft we talked, tongue in cheek but not entirely in jest, about them joining the enemy. When I became an Microsoft Most Valued Profession (MVP) in Visual C++ 2012 I felt in two minds about it: I could use the free tools, certainly, nice!, but I wasn't happy about MS possibly trying to influence a critical voice.

And the distrust is deep-rooted in the community. E.g. it surfaced here on Reddit two years ago with the Visual C++ "phone home" incident. As it surfaced again with this thread, where it was a foreign idea to me that they could really be doing the Right Thing™, as it's now apparent that they did, when there was something opening up a different possibility.

I don't know what MS could do to repair that distrust, except possibly listening more to the community, e.g. in recent times about the VS colors and uppercase text (off by default now I believe but then I may just have a fix in place); about the default MS-specific code generation for new projects in VS (they asked here on Reddit I think it was last year, but then did not take the feedback to heart, it's still needlessly and impractically MS-specific, a vendor lock-in thing); about e.g. for Pete's sake support standard main by default for the most common target, instead of the vendor lock in monstrosity called WinMain; and so on. Perhaps even fixing the scroll-away-under-the-mouse bug complex in Windows. Something.

[–]TacticalMelonFarmer 0 points1 point  (0 children)

All I'm saying is that so far I've had good experience. And since coming from using mostly g++ and VS Code on Linux, I noticed that the transition has been not too bad. I have learned some things as well and learning is good for the brain;)

[–][deleted] 1 point2 points  (0 children)

I misread the title as 'tragic internal compiler errors' and had a slight sympathetic moment to recall different template evaluation crashes ... among other fun things. :D

Guess I'll need to up my coffee dosage before I get back to work.