icsharpcode/SharpDevelop — pull request #42 by sharpmonkey (2013-06-24 04:21:08+00:00)
Title: VB.Net to C# conversion bugs

SharpDevelop Version : 4.3.1.0-00000000

# 1st Bug: VB.Net to C# converted LINQ syntax

VB.Net:
```Visual Basic
Dim value = From value In values Where value = ""someValue"" Select value
```

Should convert to C#:
```C#
var value = from value in values where value == ""someValue"" select value;
```
But it converts to:
```C#
var value = from value in valueswhere value == ""someValue""value;
```

PThere are two problems with this conversion:
- no space between where and enumerable
- missing select statement

Following test demonstrates expected output:
```C#
[Test]
public void LinqQueryWhereSelect()
{
TestStatement(@"Dim value = From value In values Where value = ""someValue"" Select value",
@"var value = from value in values where value == ""someValue"" select value;");
}
```

To fix this bug apply patch #1 (properly handle VB.Net to CS LINQ where and select output). This patch adds white space before where and implements TrackedVisitQueryExpressionSelectVBClause to output select part.

# 2nd Bug: VB.Net XML Axis Properties

Visual Basic XML Axis Properties aka VB .NET LINQ-to-XML http://msdn.microsoft.com/en-us/library/bb384769(v=vs.90).aspx

When converting from VB.Net specific way of querying XML files you end up with empty or extremely confusing C# result.

Take for an example following snippet:
```Visual Basic
Dim someDescendants = someXml...
```
which queries someXml to find all descendants named sometag and return that in form of IEnumerable.

Currently conversion to C# looks like this:
```C#
var someDescendants = someXml;
```
where we would expect something like this:
```C#
var someDescendants = someXml.Descendants("sometag");
```

Same goes for .<> (Elements) and .@ (Attributes) syntax.

To replicate this problem in current #develop code you can use following three tests:
```C#
[Test]
public void XmlLINQDescendants()
{
TestStatement(@"Dim element = someXml...",
@"var element = someXml.Descendants(""somename"");");
}
[Test]
public void XmlLINQElements()
{
TestStatement(@"Dim element = someXml.",
@"var element = someXml.Elements(""somename"");");
}
[Test]
public void XmlLINQAttribute()
{
TestStatement(@"Dim value = someXml.@attr",
@"var value = someXml.Attribute(""attr"").Value;");
}
```

To partially fix this bug you can apply patch #2 (handle VB.Net Axis LINQ syntax to CS conversion with tests) which includes and handles all three tests cases.

The reason why I mentioned partially fixed this problem is in a way VB.Net quetly handles different cases of elements and attributes syntax. While it is perfectly valid to use following syntax in VB.Net:

```Visual Basic
someElement.@someattribute = 8 ' we are setting someattribute value to 8
```
It actually translates slightly differently to C#:
```C#
someElement.SetAttributeValue("someattribute", 8); // here we have method call instead of property set
```

Following two tests replicate this scenario:
```C#
[Test]
public void XmlLINQAttributeSetConstant()
{
TestStatement(@"someElement.@someAttr = 8",
@"someElement.SetAttributeValue(""someAttr"", 8);");
}
[Test]
public void XmlLINQAttributeSetExpression()
{
TestStatement(@"someElement.@someAttr = string.Format(""{0}"", 19)",
@"someElement.SetAttributeValue(""someAttr"", string.Format(""{0}"", 19));");
}
```

To fix attribute set syntax apply patch #3 (handle VB.Net to CS conversion set attribute Axis syntax; replace assignment with call) over patch #2. As you can see from the patch we actually replace assignment expression with call expression, they way this is done is probably not the cleanest, however it did the job for my limited set of cases.