C# compiler accepts invalid C# program and produces invalid assembly by TimwiTerby

Timwi,

Hi. Thanks again for your responses. Boy this area of the C# compiler was badly broken! I've made the fix. It won't appear in the 2011 September "BUILD" conference, but it should appear by the time the next version ships.

Thanks again.

--
Lucian Wischik, VB spec lead. (and C# compiler dev).

Thanks for the extra context on how you hit this bug! We hadn't considered editing around ternary operators as a way to get into this situation - that raises the likelihood that others will hit this bug as well. I've reactivated this bug so we can take another look.

PS. Won't Fix does indeed mean "We've chosen not to fix this bug for the next release." At the beginning of each product cycle, before we start new feature work, we do a pass through our existing Won't Fix bugs, to see what set of those bugs we should reactivate and fix. However, I do agree with your concerns around the Connect site. It would be great if Connect had a better way to highlight both the bugs we're fixing and not fixing, so you can get a sense of our triage bar from the outside. The best way to get such improvements into the Connect site itself is to post your ideas to http://connect.microsoft.com/Connect.

Alex Turner
Program Manager
Visual Basic and C# Compiler

Further to my previous message — thinking about it psychologically, there is perhaps a failure of communication as it is difficult for us developers to appreciate the low impact of this bug when we do not have a broader view of the kinds of other bugs that exist that have higher impact. Sentences from you such as “the bugs that are most likely to impact developers” and “the other bugs we're choosing to fix” suggest that such higher-impact bugs exist.

Perhaps this should provide an impetus for your web development team, who maintain the Connect website, to think about this communication problem. A possible enhancement that I can envisage is some sort of feature that allows me to list other bugs similar to this one (in this case, bugs relating to the compiler/parser/codegen) which Microsoft have decided have higher impact. If I were more aware of those other bugs, it might be much easier to accept the rejection of a bug that otherwise appears too important to ignore.

Dear Alex Turner,

many thanks for your response. While I’m sure that you understand (better than I do) the possible impact of attempting to fix this, I would like to point out two things.

Firstly, you say “it's best to fix the bugs that are most likely to impact developers and lead them off on wild goose chases”. My report of this bug is due precisely to such a wild goose chase (by another developer who recounted to me at length the frustrating experience). Clearly, the bug does impact developers to the extent that you describe. Specifically, the problem occurred because my colleague used the conditional-operator syntax:

    Console.WriteLine("Foo" + (foo ? bar : baz));

In actuality the expressions “foo” and “baz” were more complex than this as this is only an example. The bug occurred because he intended to remove “foo ? bar :” but, due to the complexity of the expression (plus external factors such as tiredness and pressure from deadlines, you know what I mean), ended up removing only “foo ?”, leaving the code in a state that triggers the bug. Normally the “pit of success” philosophy of C# should catch this type of mistake. The current behaviour, which generates a crashing assembly that provides no hint of a causal link to the invalid C# code that produced it, is exactly the recipe that leads to a “pit of despair”, or as you aptly described it, a wild goose chase.

Secondly, I notice that you said “it falls below the cutoff for the next release”. However, the top of this page says “Won’t Fix”. There is a significant difference between “we can’t fix this for the next release” and “we have decided never to fix this at all”. If only the former is the case, then the status of this bug shouldn’t be “Won’t Fix” (and perhaps nor should most other bugs marked similarly). If the latter is the case, I believe our disconcertment is very justified as it is hard to imagine a more important bug than one that generates crashing software. In both cases, however, you are implying that a fatal bug such as this one is considered less worthy of attention than some minor UI changes that are being made in every release. The logic of this is very difficult to follow.

This is a case of what we call "silent bad codegen", when the compiler does produce a program, but the program is wrong. We usually consider these bugs even more serious than compiler crashes as they can be insidious and surface for customers without warning. Indeed, this is one of the worst classes of bug we see in the compilers, and would usually warrant a fix.

However, in this particular case, we're dealing not with a confluence of two language features that happens to produce the wrong IL, but rather an obvious use of named-parameter syntax where it clearly does not apply, which happens to slip through the compiler's net through a confusion between parenthesized expressions and named-parameter lists within the compiler implementation. We could indeed spend development resources cleaning up this fluke, but it would come at the expense of some other compiler bug, most likely a more subtle, more insidious bug that is far more likely to trip up developers.

Decisions about which bugs to fix will always involve tradeoffs - given a set amount of time, it's best to fix the bugs that are most likely to impact developers and lead them off on wild goose chases. While this bug may be impactful for those who happen to hit it, we believe that overall this issue is less likely to impact developers than the other bugs we're choosing to fix (be they "silent bad codegen" or simply stray compiler warnings), and so it falls below the cutoff for the next release.

Alex Turner
Program Manager
Visual Basic and C# Compiler

Sure, buggy compilers producing broken programs are no problem at all, so no need to fix this....

It appears that the vast majority of problems reported here are marked “won’t fix”. This one is a fatal crashing bug and it too got marked as “won’t fix”. What is the point in reporting any problems here if they are all being ignored anyway?

Thanks for reporting this issue you've encountered with Visual Studio!

Great catch! Unfortunately, given that using named parameters in that way is quite the corner case for the parser, we won't be able to fix this bug in the next version of Visual Studio.

Alex Turner
Program Manager
Visual Basic and C# Compiler

Thanks for your feedback. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

The background analysis shows a syntax error, but the build succeeds.