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

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 594344 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 9/3/2010 5:17:56 AM
Access Restriction Public


The C# compiler accepts the following program as syntactically valid:

        static void Main(string[] args)
            Console.WriteLine("Hello " + (args: "World!"));

However, according to my understanding of the C# grammar, it is not a valid program.

The C# compiler translates this into a CLR assembly which throws an InvalidProgramException at runtime (“Common Language Runtime detected an invalid program.”).

(By the way, the use of the word “args” is irrelevant. The C# compiler accepts this program with any identifier before the colon.)
Sign in to post a comment.
Posted by Microsoft on 9/16/2011 at 11:45 PM

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).
Posted by Alex [MSFT] on 3/17/2011 at 12:04 PM
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
Posted by TimwiTerby on 3/14/2011 at 8:19 PM
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.
Posted by TimwiTerby on 3/14/2011 at 8:07 PM
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.
Posted by Alex [MSFT] on 3/14/2011 at 7:11 PM
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
Posted by Roman.St on 1/4/2011 at 8:54 AM
Sure, buggy compilers producing broken programs are no problem at all, so no need to fix this....
Posted by TimwiTerby on 1/4/2011 at 8:53 AM
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?
Posted by Alex [MSFT] on 1/4/2011 at 2:43 AM
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
Posted by Microsoft on 9/5/2010 at 10:48 PM
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.
Posted by Microsoft on 9/3/2010 at 5:02 PM
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)
Posted by David A Nelson on 9/3/2010 at 8:55 AM
The background analysis shows a syntax error, but the build succeeds.