dotnet/roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.

The .NET Compiler Platform

Roslyn is the open-source implementation of both the C# and Visual Basic compilers with an API surface for building code analysis tools.

C# and Visual Basic Language Feature Suggestions

If you want to suggest a new feature for the C# or Visual Basic languages go here:

• dotnet/csharplang for C# specific issues
• dotnet/vblang for VB-specific features
• dotnet/csharplang for features that affect both languages

Contributing

All work on the C# and Visual Basic compiler happens directly on GitHub. Both core team members and external contributors send pull requests which go through the same review process.

If you are interested in fixing issues and contributing directly to the code base, a great way to get started is to ask some questions on GitHub Discussions! Then check out our contributing guide which covers the following:

• Coding guidelines
• The development workflow, including debugging and running tests
• Submitting pull requests
• Finding a bug to fix in the IDE or Compiler
• Finding a feature to implement in the IDE or Compiler
• Roslyn API suggestions should go through the API review process

Community

The Roslyn community can be found on GitHub Discussions, where you can ask questions, voice ideas, and share your projects.

To chat with other community members, you can join the Roslyn Discord or Gitter.

Our Code of Conduct applies to all Roslyn community channels and has adopted the .NET Foundation Code of Conduct.

Documentation

Visit Roslyn Architecture Overview to get started with Roslyn’s API’s.

NuGet Feeds

The latest pre-release builds are available from the following public NuGet feeds:

• Compiler: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json
• IDE Services: https://pkgs.dev.azure.com/azure-public/vside/_packaging/vssdk/nuget/v3/index.json
• .NET SDK: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json

Continuous Integration status

Builds

Branch	Windows Debug	Windows Release	Unix Debug
main
main-vs-deps

Desktop Unit Tests

Branch	Debug x86	Debug x64	Release x86	Release x64
main
main-vs-deps

CoreClr Unit Tests

Branch	Windows Debug	Windows Release	Linux
main
main-vs-deps

Integration Tests

Branch	Debug x86	Debug x64	Release x86	Release x64
main
main-vs-deps

Misc Tests

Branch	Determinism	Analyzers	Build Correctness	Source build	TODO/Prototype	Spanish	MacOS
main
main-vs-deps

.NET Foundation

This project is part of the .NET Foundation along with other projects like the .NET Runtime.

roslyn's Issues

Do not require type specification for constructors when the type is known

Do not require type specification for constructors when the type is known.

Imagine this case:

Dictionary<string, List<int>> d = new Dictionary<string, List<int>>();

becomes:

Dictionary<string, List<int>> d = new();

Obviously, constructor arguments and object initialization would be allowed.

This might be a simple optimization given the above example, but there are longer type specifications out there.

But when applied to this:

XmlReader.Create(reader, new XmlReaderSettings{ IgnoreWhitespace = true });

it would become this:

XmlReader.Create(reader, new{ IgnoreWhitespace = true });

which is a lot more readable. In cases like this, the type is not really important, its properties are.

Simplifier removes trivia when eliminating 'this.' uses.

Consider the following code:

class C1
{
    int _field;

    void M()
    {
        this. /* comment1 */ _field /* comment 2 */ = 0;
    }
}

If the MemerAccessExpressionSyntax for the field access is tagged with Simplifier.Annotation and the result run through the Simplifier the code will be transformed into.

class C1
{
    int _field;

    void M()
    {
        _field /* comment 2 */ = 0;
    }
}

Notice that /* comment 1 */ has been removed. That seems like a bug. Removing non-comment trivia seems acceptable here but removing comments is potentially removing valuable documentation during the act of simplification. At the least it seems like there should be an option to prevent this from happening.

SyntaxFactory.NameOfExpression(...) should have an overload that doesn't require "nameof" as first argument

I'm generating code that includes nameof expressions and was very surprised that SyntaxFactory.NameOfExpression took two parameters: "nameof" itself, and then the expression that goes in as the argument of 'nameof'. Since the nameof expression is always going to be "nameof", should there be an overload of this method that will specify this automatically?

Incorrect simplification of Nullable{T} in XML comment

The following shows an incorrect Simplify name proposal for a reference to Nullable<T> within an XML documentation comment.

This can be reproduced in Visual Studio 2015 Preview (CTP 4?) and CTP 5 with the following code:

/// <summary>
/// The <see cref="Nullable{T}"/> type has been defined not using the C# shorthand.
/// </summary>
public class Foo
{
}

AnalyzerDriver<T>.Dispose is broken

http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis/DiagnosticAnalyzer/AnalyzerDriver.cs,951

This should override the base method, not shadow it. (preferably using the standard dispose pattern)
@amcasey points out that it should also skip the loop entirely if lazyNodeActionsByKind has not been initialized.

Also, is that property getter supposed to be thread-safe?
If called on multiple threads, you will leak the pool.
Why not use Lazy<T>?
Are you trying that hard to save allocations?

Allow anonymous objects to implement IDictionary<string,object>

A pattern used in some libraries is to pass an anonymous object around to act as a key-value pairing. For example in Dapper

conn.ExecuteScalar<int>(@"select count(*) from dbo.some_table
 where name=@name and date=@date",new{name="Joe",date=DateTime.Today})

To enable this lightweight key-value pairing the library authors has to write somewhat annoying reflection based code to find the properties to get their name and values. The authors of said libraries also often are required to create delegates to parse this anonymous object to keep it quick.

Unfortunately, anonymous objects shipped without this feature. It would be nice to maybe with an alternative syntax allow declaring anonymous objects that implement IDictionary<string,object>.

Another alternative, could be basically a lightweight syntax to declare Dictionary literals. Array is nice and light, but dictionaries are pretty noisy. Even the "new" syntax is pretty lousy.

    var new_style_dict = new Dictionary<string,object>{["name"]="joe",["date"]=DateTime.Today};
    var old_style_dict = new Dictionary<string,object>{{"name","joe"},{"date",DateTime.Today}};

But it'd probably nice to keep it immutable so you don't have to worry about the parameter being changed by what you are calling.

Allow local variables to be static and/or readonly (deeper scoping)

Proposal

Allow local variables (within method blocks) to be marked as static, readonly, or static readonly.

Purpose

This would allow a developer to have the advantage of static and readonly fields, but limit their usage to a fine-grained scope.

Example:

class Foo
{
    public void Method()
    {
        static readonly var codes = new[] { 1, 7, 10 };
    }
}

This would help alleviate situations such as reallocating a new array (and assigning the value to fibonaccis) upon each execution of Method():

class Foo
{
    public void Method()
    {
        // This should be static readonly, but only accessible in this method.
        var fibonaccis = new int[] { 0, 1, 2, 5, 8, 13, ...,  701408733 };

        ...
    }
}

Or, it could help avoid potential issues with static field being accessible outside of its intended scope, purposefully or accidentally:

class Foo
{
    // This variable should only be used in Method().
    // Please do not change its value on me somewhere else!
    private static int _methodCount = 0;

    public void Method()
    {
        var count = ++_methodCount;

        ...
    }
}

Implementation

The Roslyn compiler could recognize the syntax and generate the necessary IL code, just as it does for automatic properties, async/await, foreach, etc.

Originally, the discussion from codeplex talked about the potential issues and confusion, and the final thought I had was to lift the local variable as a Lazy<T> and for this feature to be purely syntactic sugar. After researching how VB.NET implements local static variables, the compiler does a bit more work to generate the correct IL code. See this article: http://weblogs.asp.net/psteele/7717. I think the same thought should be put into C#.

While the article only talks about static local variables, I think that there would be real value to also allow the readonly keyword to be used as well. The complexity would grow, of course, because we have four possible situations (instead of just two):

• static without initialization (already supported by VB.NET).
• static with initialization (already supported by VB.NET).
• readonly with initialization (not supported by any language).
• static readonly with initialization (not supported by any language).

Feature request: Anonymous types that implement interfaces

It would be very useful if C# anonymous types could implement interfaces, including methods. This would make a huge difference when developing using interface driven design. It would also allow for very easy mocking in unit tests.

interface IFooBar {
    string Foo { get; }
    int Bar(string s);
}

void MethodA () {
    // explicitly typed
    var myFooBar = new IFooBar {
        Foo = "xyz",
        Bar = s => s.Length
    };

    MethodB(myFooBar);
}

IFooBar MethodB(IFooBar fooBar) {
    // implicit typed
    return new {
        Foo = "abc",
        Bar = fooBar.Bar
    };
}

In TypeScript and other dynamic languages, this has proven to be really useful and reduces a lot of boilerplate code.

It seems that implementing this in C# wouldn't break any rules as anonymous types are already classes internally, and the compiler could just make it implement the interface and use the same rules for checking type.

The only issue I can think right now is the method implementation. How to differ between a method and a property that is a delegate:

interafce IFoo {
    int Bar(int i);
    Func<int, int> Baz { get; }
}

void IFoo GetFoo() {
    return new {
        Bar = i => 1, // ?
        Baz = i => 2; // ?
    }
}

It seems that from the perspective of the C# consumer it wouldn't make much difference, as both can be called using the same syntax (obj.Bar() or obj.Baz() ), but the compiler needs to know this.

This could be solved by either adding a new syntax to this implementation:

void IFoo GetFoo() {
    return new {
        Bar(int i) => 1,   // method
        Baz = i => 2;  // deletage
    }
}

Or by just defaulting to methods unless the interface calls for a property. That would make the first example with the same code valid, and I guess would make the syntax better.

CCRewrite unhappy with Toolset Compilers 1.0.0-rc1-20150113-03

After upgrading from to Microsoft.Net.ToolsetCompilers.1.0.0-beta2-20141216-04, CodeContract ccrewrite.exe (latest, v1.7.11202.10) starts to fail during build with:
error CC1099: Contract extraction failed: Found field <>8__1 in contract that shouldn't be here: In method ns.type.member.
Exact same code had no issue with Microsoft.Net.ToolsetCompilers.1.0.0-beta2-20141223-03.
Function exhibiting error is in a static class, along the lines of:

public static IEnumerable<tuple<object, MemberInfo, LinkArity, int, LinkDirection, object, LinkOutput>> BreadthFirstTraversal(
        object fromObject,
        Func<object, IEnumerable<Tuple<MemberInfo, LinkArity>>> getSubjectRelations,
        Func<object, MemberInfo, LinkArity, IEnumerable<Tuple<int, object, LinkOutput>>> getRelatedObjects,
        IEqualityComparer<object> nodeComparer = null
        )
    {
        Contract.Requires<ArgumentNullException>(getSubjectRelations != null);
        Contract.Requires<ArgumentNullException>(getRelatedObjects != null);
    ...

so with only 2 simple preconditions. Function body uses yield return after that.
Commenting out the contracts removes the build error.
This only occurs in a few instances overall, the majority of contracts are unaffected, but I haven't identified the exact pattern causing that issue yet.
In another instance, ccrewrite goes through, but runtime behavior becomes faulty with a precondition asserting systematically.

Grammar issue in SourceTextContainer exception message

TextEditorResources.TextcontainerIsNotAnSource in EditorFeatures.Text reads

textContainer is not an SourceTextContainer that was created from an ITextBuffer.

That should be a, not an. (I assume it used to be an interface)

Feature: Parameter Name Aliasing

The human meaning of parameters may vary from method caller's perspective.

It would be useful if the language provides an ability to assign aliases to the parameters.

[Alias({second: [secondAndHalf, quarterToThree], first: [Initial]})] 
public static void Member1(string first, string second) { 
  // Here the user will always use the given names: first and second.
  // which means the user cannot use the param by its nickname
  // inside the method scope.
}

private static void Caller1() {
  Member1(secondAndHalf: "secondly, this is not a bad idea after all",
          Initial: "Initially it sounded moot... :)  ");
}

private static void Caller2() {
  Member1(first: "1st",
          quarterToThree: "almost there");
}

private static void Caller3() {
  Member1("one", "two");
}

vs. this current approach:

public static void Member1(string first, string second) {  }

public static void Member1(string first, string secondAndHalf, string devNull = null) { 
  Member1(first, secondAndHalf);
}

Note: the parameter devNull may violate CA1026, in case of overridden methods. On the flip side, setting devNull as non-default parameter would yield "unused parameter".

Related / Real world example: madskristensen/WebEssentials2013#380 (comment)

Feature request: Implicitly typed lambdas

Currently, it is not possible to do this:

var x = () => 1;

Instead, you need to declare the type before:

Func<int> x = () => 1;

C# should just assume these kind of lambdas are either Action or Func and infer the type.

Usually these lambdas are used as helpers for the method implementation, so it really wouldn't matter if a (string s) => true is a Func<string, bool> instead of a Predicate<string> as long as the signature matches.

Automatic Interfaces

This is a feature request. I don't know whether this is more of a language or IDE feature, but I can imagine it going either way.

Problem

Consider the process of setting up a dependency injection environment for a class HomeController that depends on another class, DataAccess.

This process would typically (for me, at least) looks something like this:

1. Create DataAccess
2. Build an interface IDataAccess with exactly the same items (Visual Studio does this through a menu-item)
3. Add a field and constructor (easy with the new constructor syntax) for HomeController that accepts IDataAccess dataAccess

That's pretty straight-forward.

But once you start changing those contracts, it gets a little more frustrating.

1. Starting in HomeController, go find DataAccess (note that F12 doesn't work, since we're only looking at the interface at best here. You can F12 to the interface, then look at references to find the class, but...)
2. Add the desired method to DataAccess
3. Copy the method signature, then scroll to the top of the file (often a ways) and F12 to IDataAccess
4. Paste the signature into the interface
5. Go find HomeController again and write the line I wanted.

In reality, I often do this backwards via Ctrl+. by referencing a non-existent method, creating the method stub, then implementing the interface.

Proposal

It seems like we could do away with many of these steps using an interfaceof(T) language feature, similar to typeof or nameof. I can also see it as HomeController.interface.

In essence, interfaceof(T) would build a compile-time interface out of T that can be used just as we used IDataAccess before. The compiler would build a logical interface identical to what the IDE would when I right-click a class name.

1. Create DataAccess
2. Add a field and constructor (easy with the new constructor syntax) for HomeController that accepts interfaceof(DataAccess) dataAccess

Simple still.

Then for the other steps,

1. Starting in HomeController, go find DataAccess (note that F12 does now work, since we have the class referenced here)
2. Add the desired method to DataAccess
3. Go find HomeController again and write the line I wanted.

My personal preference of adding the unknown method reference first then creating it with ctrl+. is also supported, since it will automatically add onto DataAccess.

If I wanted to inject something else, I could use very similar syntax:

public class DataAccessMocks : interfaceof(DataAccess)

If I had those mocks set up and building with my main project when I added a method, they would raise a compiler error because it didn't implement the (whole) interface.

In essence, I see this kind of as a reverse version of an abstract class. In an abstract class, as we know, the class can decide (or force) "I want children to inherit from me." Using interfaceof, the recipient of that class can say `I don't care whether what I receive has a polymorphic relationship with this class, but I do need its contract maintained exactly."

Potential Concerns

Now, of course, this isn't an alternative to interfaces. Interfaces do a whole lot that isn't useful here, particularly in that to use this interface, one would have to maintain a reference to DataAccess. It's mostly useful in this specific (albeit common) case of dependency injection.

Does this approach, when not in the light of dependency injection, open itself to any bad practices? If overused, this could offer some interesting security holes in code. Imagine if I accepted an interfaceof(DateTime) in the interest of having as open a contract as possible, but then someone passed me something that implemented the DateTime members very poorly. Could that be problematic? This seems like it would be either my fault, or that of the caller.

Conclusion

This seems like it could clean up a lot of dependency injected code, and it might even have alternative uses that I haven't immediately thought of. The current procedure is painstaking, and I'd love some more efficient way of handling this very common scenario.

Question: ScriptEngine

Is there going to be any signs of ScriptEngine in the final release of Roslyn as we saw in previous CTP?

Intellisense Tooltip get too long in case of many generic parameters

Hi, I hope to be in the right place, if not feel free to close this.

I noticed that Intellisense tool-tips become too long in case of many generic parameters with constraint, see image below.

What I would like to see, if there are more than 1 generic constraints is to split every constraint in a new line (as you can see in generic constraint declaration on the class itself) to avoid creating a very long tool-tip and to gain readability

M.

Strongly-typed type aliases

I would love to see strongly-typed type aliases in the C# programming language. These would be roughly equivalent to types declared in Haskell using newtype. Such aliases would be very different from regular aliases declared using using statements since the source-level type would ultimately be erased by the compiler. However, they would behave as distinct types from the original type during compilation time.

I think this would be very helpful for dealing with easily abused types such as string. Here's an example using a hypothetical new language structure using the newtype keyword:

using System;
newtype EmailAddress = System.String;

class Program
{
    static EmailAddress CreateEmailAddress(string text)
    {
        // Valid: use cast-style syntax to "convert" string to EmailAddress
        return (EmailAddress)text;
    }

    static void UseEmailAddress(EmailAddress emailAddress)
    {
        // Valid: everything has ToString
        Console.WriteLine(emailAddress);

        // Invalid: EmailAddress does not directly expose Length
        Console.WriteLine(emailAddress.Length);

        // Valid: EmailAddress instance can be explictly converted back to System.String
        // Does not result in runtime conversion since EmailAddress type is erased by
        // compiler
        Console.WriteLine(((string)emailAddress).Length);
    }

    static void Main()
    {
        // Valid
        UseEmailAddress(CreateEmailAddress("[email protected]"));

        // Invalid
        UseEmailAddress("[email protected]");
    }
}

This is purely syntactic sugar, however, and the compiler will emit all references to type EmailAddress as references to System.String instead. Perhaps some additional metadata could be applied to arguments of these alias types to provide a hint to compilers about the original (source-level) type assigned to it. There are obviously many questions that arise. The main one, I think, is what to do about methods that are declared on the original type: if they are all projected onto this new "virtual" type, then we lose all advantages of this new type safety. I believe that the compiler should prohibit the developer from calling any of the original type's members on a reference to the alias type without inserting an explicit cast back to the underlying type. Such a cast would be purely syntactic and would not incur any runtime overhead.

In traditional C# programming, the developer would most likely wrap a string inside an EmailAddress wrapper class to ensure type safety and to curate access to the underlying string. My proposed language feature would enable the developer to more elegantly express certain concepts without bloating the code with wrapper classes. Importantly, it would also allow generation of extremely efficient code.

More issues:

• What is the scope of a type declared with newtype?

Perhaps newtype could look more like the definition of a class or struct:

namespace MyNewtypeDemo
{
    using System;

    // No inheritance: this is an alias
    // Only methods declared inside the "newtype" declaration
    // can access the members of "string": no casting required
    // We'll reuse the contextual keyword "value"
    public newtype EmailAddress : string
    {
        // Constructor: can assign to "value" which is the actual string
        // Can only initialize via constructor
        public EmailAddress(string text)
        {
            if (!IsValidEmailAddress(text))
            {
                throw new ArgumentException();
            }

            // No cast required since compiler knows that "value" is a string
            value = text;
        }

        // Length is not normally accessible but we can wrap call to value.Length
        public int Length
        {
            get { return value.Length; }
        }

        public string ToActualString()
        {
            return value;
        }

        private static bool IsValidEmailAddress(string text)
        {
            // Validate text etc.
            return true;
        }
    }
}

Allow C# to use anonymous iterators.

VB.net allows you to have a lambda return an iterator, it should hopefully be possible to use such functionality in c#. E.g.

Func<IEnumerable<int>> f = ()=>yield return 3;

While that's a terrible example it hopefully can demonstrate the point.

SimpleDiagnostic GetHashCode is inconsistent

To make Microsoft.CodeAnalysis.Diagnostic work with Sets and other data structures that requires GetHashCode to be implemented correctly you have to have a GetHashCode method with this property:
x.Equals(y) \implies x.GetHashCode() == y.GetHashCode() \forall x,y

Currently SimpleDiagnostic's GetHashCode combines the hash codes of its properties including a GetHashCode on the object[] messageArgs which is using the reference to that array, not its contents to generate the hash code. Equals however is comparing the objects in the array (using Enumerable.SequenceEqual) . So currently you can have two diagnostics that are Equal in terms of IEquatable.Equals but with GetHashCode returning different values.
http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis/Diagnostic/Diagnostic_SimpleDiagnostic.cs,134
http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis/Diagnostic/Diagnostic_SimpleDiagnostic.cs,120

Adding semicolon inbetween property name and { get; set; } invalidates rest of the document (excess errors)

Repro:

public class Class
{
    public int MyProperty; { get; set; }

    // Pretty much anything here causes an error
}

Note the ; after MyProperty and before { get; set; }

Expected:
Rest of document not being invalidated and an error that points to the property.

Notes:

When generating code for Razor there have been some cases of users adding semicolons after @inject statements resulting in the entire document being invalidated (tons of errors) after

Add more type-inferencing to C#

For instance, when you have code such as:
public static int Add( int x, int y )
{
return x + y;
}

Why do you have to specify "int"? You can simply say:
public static Add( x, y )
{
return x + y;
}

I realize that's what Generics are for, and maybe that's how the above will get implemented. Note that this is not about dynamic typing. The above code very much is aware of types, but it works like generics do. Also, we'll have to have automatic handling of constraints on the implicit type parameters. You should have to specify a "where" keyword. For instance, remove the need to say something like:
where T : new()
when you see the code do a new.

So this type of code:
class ItemFactory
{
public GetNewItem()
{
return new typeof(return)();
}
}

changes into this type of code internally:
class ItemFactory where T : new()
{
public T GetNewItem()
{
return new T();
}
}

Then specifying a type in code will be mostly when you instantiate it. The rest of the code attempts to infer it.

Unable to compile conditional access expression in context of expression-bodied void method/lambda expression

Related commit: dd8f041

?. invocation in context of a statement-expression should be allowed even if result type of the invocation cannot be made nullable.

I'm expecting it also to work with void methods in expression-bodied form, as well as void lambda expressions:

using System;

class C<T> {
    void F1(C<T> c) {
        c?.M(); // compiles fine

        // error CS0023: Operator '?' cannot be applied to operand of type 'T'
        Action a = () => c?.M();
    }

    // error CS0023: Operator '?' cannot be applied to operand of type 'T'
    void F2(C<T> c) => c?.M();


    T M() => default(T);
}

Feature Request : Make internals public

There are various places in the codebase we'd like to use for OmniSharp but they are marked as internal for example http://source.roslyn.codeplex.com/#Microsoft.CodeAnalysis.CSharp.Workspaces/Extensions/ContextQuery/CSharpSyntaxContext.cs

Could you open most of the classes marked internal and sealed to public please?

API Proposal: OptionSet handling

• Currently OptionSets are handled at Workspace level. Moving them to the Project level would allow more fine grained option scenarios.

-Why it's not possible to create own option sets or provide option services ?

In general the option API seems to be tailored for a 'read only' use.

Feature Request: Recursive Iterators (non-quadratic)

Current if you want write a recursive based iterator function.

Iterator Function TreeWalk(Of T) ( curr As BinaryNode(Of T)) : IEnumerable(Of BinaryNode(Of T))
  If curr Is Nothing Then Return Enumerable.Empty(Of BinaryNode(Of T))
  ForEach node In TreeWalk( curr.Left )
    Yield node
  Next
  Yield curr
  ForEach node In TreeWalk( curr.Righ )
    Yield node
  Next
End Function

it ends up being Quadratic runtime

If I could express the Iterator / Yielder as a parameter I could linearise the runtime.

Iteration Function TreeWalk( n : BinaryNode, iterator As ?? ) : IEnumerable(Of T)
  If n Is Nothing Then Exit Functon
  If n.Left IsNot Nothing Then TreeWalk(n.Left, Iterator)
  Yield n.Value on Iterator
  If n.Righ IsNot Nothing Then TreeWalk(n.Righ, Iterator)
End Function

SemanticModel.GetArgumentInfo API needed to retrieve the IParameterSymbol that an ArgumentSyntax binds to

This is a missing API. Writing a diagnostic that process an argument requires a fair amount of code to determine what parameter the argument binds to -- checking for named or positional arguments.

Renaming C# symbols reports errors

After running Visual Studio 2015 for a while, renaming stops working, reporting an error: "Object reference not set to an instance of object." Repro is difficult, because when first launching VS, rename works just fine. Dumps aren't retrievable, because VS doesn't crash when this issue happens.

Things to try

1. Create an ASP.NET MVC project with a Cloud Service project.
2. Build and run the project at least once. Terminate project execution.
3. Press F2 over an existing symbol defined in the project.
4. Add one or two new classes (controllers or views may work, too).
5. Press F2 over the new class name.

Expected

• The rename box appears, the symbol name is highlighted, and the user can rename the symbol.

Actual

• Error dialog appears with the message: "Object reference not set to an instance of object."

Rename: Invoking rename when there is an active session should commit

Expose RQNameService.TryBuildForPublicAPIs to enable language interop in VS.

Some Visual Studio features use RQNames to communicate symbols. It would be nice if there was a way to get the RQName for an ISymbol publicly.

Allow support for params IEnumerable<T> methods

Currently, C# only supports params T[], however it is rare that I actually need an array for my method. More often than not, I merely want iteration or to perform some sort of LINQ operators against the parameter. In fact, it is common for libraries to declare a version of the method that takes an IEnumerable and a T[], and have the T[] version call the IEnumerable variant.

The implementation detail could still be that an array is made at the call site and sent to the method, the benefit is to simply avoid having to create the extra overload.

Ability to reference a method group in XML comment

Currently the following works:

/// <summary>
/// Reference to a method group with one item: <see cref="Foo"/>
/// </summary>
void Foo() { }

However, the following does not work:

/// <summary>
/// Reference to a method group with two items: <see cref="Foo"/>
/// </summary>
void Foo() { }
void Foo(int x) { }

The specific warning produced is:

warning CS0419: Ambiguous reference in cref attribute: 'Foo'. Assuming 'TypeName.Foo()', but could have also matched other overloads including 'TypeName.Foo(int)'.

To reference a method group, the following syntax is required:

/// <summary>
/// Reference to a method group with two items:
/// <see cref="O:Full.Declaring.Namespace.TypeName.Foo"/>
/// </summary>
void Foo() { }
void Foo(int x) { }

This is problematic for the following reasons:

1. ❗ The syntax is not validated during the build. Errors made while typing are not reported until if/when Sandcastle Help File Builder processes the comments.
2. ❗ The syntax is extremely verbose.
3. ❗ The syntax only works if there are more than one method with the same name.
4. ❗ There is no syntax highlighting or editor support for this syntax.

I propose the following changes:

1. 💡 If no argument list is provided and the method group contains exactly one method, compile the comment as a direct reference to that method. (This is how the compiler already behaves for this case.)
2. 💡 If no parameter list is provided and the method group contains more than one method, compile the comment as a reference to the overloads of the method, with the O: form listed above.

Expose API similar to AnalysisContext within the Workspace API

I've been developing a few extensions for Visual Studio and have been consuming the VisualStudioWorkspace.WorkspaceChanged event. This event doesn't tell me anything more than "Document X has changed".

The AnalysisContext API looks like a much richer experience. (I haven't actually built any Analyzers myself). It appears to allow analyzers to wait for compilations, semantic models for individual files and more.

Waiting for a background compilation to have completed sounds particularly appealing to me. I don't want my extension to be responsible for triggering unnecessary compilations. I'd be interested to hear from other VS Extension authors who have also used the VisualStudioWorkspace.

Method Declaration in Script code shows completions for class

Source: (in a Script document)

public static bool HasAtLeast<T>(this IEnumerable<T>

Pressing Ctrl+Space on the bool shows just class, partial, and unsafe.

VB LDM 2015.01.14 - overload resolution for string interpolation

Note: we will post the notes of "Language Design Meetings" here as issues. We will leave them open for comments for one week, and then close them.

Summary

• Exactly like C#, we will consider an interpolated string to be like a string in most cases such as overload resolution and searches for user-defined/intrinsic conversion. This implies that what the IDE intellisense shows after $"hello".| should be the same as that for regular strings.
• We wrote out some gnarly type-inference test cases for overload resolution and array literals with interpolated strings, and explained the expected output.
• We would like both C# and VB to give more actionable error messages if they end up binding to a factory Create method whose return type isn't right
• We reaffirmed intended behavior for full-width characters in interpolated strings

Overload resolution for string interpolation

We want interpolated strings to be easily used as both String and FormattableString:

  Dim x As String = $"hello {p}"              ' works fine
  Dim x As FormattableString = $"hello {p}"   ' works fine
  Dim x = $"hello {p}"                        ' works fine, and infers x As String

The question is about overload resolution... Which candidate should it prefer? Or should it be an ambiguity error?

  Sub f(x As FormattableString) : End Sub
  Sub f(x As String) : End Sub

  f($"hello {p}")    ' ... which does it pick?

One important principle is that if there's an existing API Sub f(x As String) then consumers MUST be able to call it with f($"hello {p}").

Another question is: if there's a language intrinsic conversion from string, does that conversion also apply to interpolated strings? e.g.

   Dim x As Char() = "hello people"  ' works fine
   Dim x As Char() = $"hello {x}"    ' should this also work?

And separately, if there's a user-defined intrinsic conversion from string, does that conversion also apply to interpolated strings?

(In C# the intention is that both should work. Have to verify that we've covered that in unit tests.)

API DESIGN Proposal 1a

"Some library APIs really want consumers to use FormattableString because it is safer or faster. The API that takes string and the API that takes FormattableString actually do different things and hence shouldn't be overloaded on the same name. Library authors will want to lead people to use interpolated strings, hence it should have a shorter name."

   Sub ExecuteQueryUnsafe(s As String) ...
   Sub ExecuteQuery(s As FormattableString) ...

   Sql.ExecuteQueryUnsafe(GetRegValueEx(path))
   Sql.ExecuteQueryUnsafe("from p in people select p.Name")
   Sql.ExecuteQuery($"from p in {x} select p.Name")

Q. If they do different things, then wouldn't you want an ambiguity error here?

API DESIGN Proposal 1b

"In other library APIs, strings and FormattableStrings are equally fine; overloads make sense; we should prefer string overload because it will be more efficient"

   Sub WriteLine(s As String) ...

   Console.WriteLine("hello everyone")
   Console.WriteLine($"hello {fred}")

Q. Isn't it an antipattern for an API to have both String and FormattableString if they just do the same thing?

A. Well, maybe, but it could be valid and useful to overload on both String and IFormattable. (Or an overload of both String and Object and then do a TryCast to IFormattable).

Proposal 2

"I don't like Safe/Unsafe. How about these names? ..."

   Sub ExecuteQuery(s As String) ...
   Sub ExecuteQuery(s As FormattableString) ...

   Sql.ExecuteQuery(GetRegValueEx(path))
   Sql.ExecuteQuery("from p in people select p.Name")
   Sql.ExecuteQueryWithFormat($"from p in {x} select p.Name")

API DESIGN Proposal 3

"Someone will start with ExecuteQuery, and when they change the argument to $ then they won't see or understand the differently-named method. So let's pick the FormattableString overload which is most likely to be safe."

   Sub ExecuteQuery(s As String) ...
   Sub ExecuteQuery(s As FormattableString) ...

   Sql.ExecuteQuery("from p in people select p.Name")  ' picks String overload
   Sql.ExecuteQuery(GetRegValueEx(path))  ' picks String overload
   Sql.ExecuteQuery($"from p in {x} select p.Name")  ' picks FormattableString overload

Q. What about the following consequence? Imagine an API has existed whose behavior is to format its string in a particular culture

   Sub f(x As IFormattable)
   f($"hello {p}")

And later on down the line someone adds a new overload that takes string

   Sub f(x As String)

Then the user's call will change behavior upon recompilation.

RESOLUTION

We generally believe that libraries will mostly be written with different API names for methods which do different things. Therefore overload resolution differences between FormattableString and String don't matter, so string might as well win. Therefore we should stick with the simple principle that an interpolated string is a string. End of story.

Implication: in intellisense $"hello".| will show extension methods off String, but will NOT show extension methods off FormattableString.

Implication: both intrinsic and user-defined conversions that apply to string will also apply to interpolated string

Implication: overload resolution will prefer String over FormattableString candidates when given an interpolated string argument.

Implication: type inference works as follows.

Sub f(Of T)(x As T)
f($"hello {p}")
' then it picks string. (it has *contributed* string as a candidate)

Sub f(Of T)(x As T, y As T)
f($"hello {p}", CType(Nothing, FormattableString))
' Then it gets two candidates, "String" and "FormattableString"
' In most of the language (other than array literals), it checks whether
' the *type* of each argument can convert to the candidate type.
' In this case it will give an error.

Implication: if you have an array literal that contains an interpolated string expression

   Dim x = {$"hello", CType(Nothing, IFormattable)}

then this will pick "Object Assumed" in Option Strict Off, and give an error in Option Strict On. The reason is that there is no dominant type between the candidate types "String" and "IFormattable". (There's no widening/identity conversion from one to the other, and there is a narrowing conversion from each to the other).

About the factory method that interpolation strings use

The language conversion rules bake in knowledge of System.IFormattable and System.FormattableString for their knowledge of widening conversions.

The compiler emits a call to a factory method when there is an interpolated string in source code. The factory method looks like this. There might be a whole family of overloaded Create methods.

System.Runtime.CompilerServices.FormattableStringFactory
   Function Create(...) As ...

The compiler separates the interpolated-string into a format string and a comma-separated list of expressions for the holes which it classifies as values before generating a call to Create(fmtstring, expr1, expr2, ...). It will rely on normal VB overload resolution to pick the best Create method. This leaves the implementors of the factory free to do lots of nice optimizations.

The question is, what return type do we expect from the Create method?

Option1: We could bake in the requirement that the factory method gives back a System.FormattableString, and this type must implement System.IFormattable, and do this as a pre-filter prior to doing overload resolution of the Create() overload family.

Option2: Or we could merely invoke the method, and do a cast of the return type to IFormattable/FormattableString depends on what the user asked for. But then...

• Do we give a warning if it has the [Obsolete] attribute?
• Do we give a warning if it is narrowing?
• What if it picks a Sub() ?

Option3: Just do plain ordinary overload resolution, and if there were ANY errors or warnings, them emit them. In addition, if there were any errors (not just warnings that happened to be WarnAsError'd), then additionally report an error message at the same location "The factory is malformed". Precedent: we do this for queries. [Note: this message might appear or disappear if you change option strict on/off in your file].

Option4: As with Option3 but enforcing it to use Option Strict On for its overload resolution and its conversion to IFormattable/FormattableString.

RESOLUTION: Option3.

Q. What about delegate relaxation level of $"hello" to FormattableString/IFormattable ?

Sub f(lambda as Func(Of FormattableString))
Sub f(lambda as Func(Of String))
f(Function() $"hello")

RESOLUTION: From the principle above, we'd like this to pick the String overload. The way to accomplish this is to classify the lambda conversion as DelegateRelaxationLevelReturnWidening.

Q. What about full-width characters?
e.g. does $"{{" give the non-full-width string "{" even if the two source characters had different widths?
e.g. can you write $"{p}" where the open is wide and the close is normal width?
e.g. there is no escape to put a full-width {, similar to how there's no escape to put a full-width " ?

RESOLUTION: Yes that's all fine.

---

These are the workitems left to do...

C#: additionally report error message about bad factory
C#: verify (add a test case) that user-defined and intrinsic conversions on string really are used for interpolated strings.
VB: change array literal dominant type stuff
VB: all the dominant type stuff
VB: fix up delegate relaxation level to be widening (and write test for it)

Build and Unit test failures in 'master' branch

To carry on the CodePlex discussion with @MattGertz and @KevinRansom, I'm still seeing many unit test failures on the GitHub master branch. I assume you are still working on this as part of the move to GitHub but I thought it might be helpful to report the issues I'm seeing right now.

I created a clean VS2015 CTP5 machine on Azure today, installed the CTP SDK, cloned Roslyn (at the time master's HEAD was 7fed8e8) and ran msbuild /m BuildAndTest.proj /p:DeployExtension=false.

Here are the problems I saw:

Build Failure

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\VSSDK\Microsoft.VsSDK.targets(760,5):     error : CreatePkgDef : error : FileLoadException: Could not load file or assembly 'OpenSourceDebug,    Version=42.42.42.42, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its    dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)   [c:\dev\roslyn\Src\Tools\Source\OpenSourceDebug\OpenSourceDebug.csproj]

I ran sn -Vr *,31bf3856ad364e35 to work around this.

Crashes during test run

When the tests run, for every test tries to launch the command line compiler (and there are many), a crash dialog pops up saying that "VBCSCompiler has stopped working" or "csc.exe has stopped working". I also got an error saying:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'csc,Version=42.42.42.42, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---

Again, this seems to be related to strong name validations, and this time the fact I SN -Vr'ed that same public key didn't help. To get past the crash dialogs, I manually deleted Roslyn.Compilers.CompilerServer.UnitTests.dll Roslyn.Compilers.CSharp.CommandLine.UnitTests.dll and Roslyn.Compilers.VisualBasic.CommandLine.UnitTests.dll, and then ran:
msbuild /target:test /m BuildAndTest.proj /p:DeployExtension=false

Remaining unit test failures

Finally, the resulting UnitTestResults.html file reported 2 unit test failures, while the command-line window consistently reported 39.

Application of formatting rules changed in 1.0.0.0-beta2

One of the StyleCop analyzers we implemented (SA1408) adds parentheses around certain expressions in code. The code fix provider implementation does not use Formatter.Annotation, and we have a unit test which verifies the code fix does not alter existing formatting aside from adding ( and ) characters.

The unit test in question was successful in the Beta 1 code. With no change aside from updating to Beta 2, the test now fails.

Here is the affected expression as produced by Beta 1:

bool z = z ? (true&&true)||false :false;

Here is the affected expression as produced by Beta 2:

bool z = z ? (true && true) || false :false;

The two expressions differ by a total of 4 space characters.

Questions:

• ❓ Is there a way to cause Beta 2 to behave like Beta 1? Our diagnostics and code fixes relate specifically to code formatting so they will not work if the implementation changes unrelated formatting.
• ❓ Was the behavior change in Beta 2 intended, and/or will it be reverted in the next release?

Code completion for Null conditional element access operator only works on simple name expressions

Open up VS 2015 CTP 5 and type:

String s = "g";
s?[ (At this point the parameter completion popup appears as it's supposed to)

Now try the following expressions:

new String() ?[ (Popup DOESN'T come up)
""?[ (Popup DOESN'T come up)
(" ")?[ (Popup DOESN'T come up)

Add symbol files(.pdb/source) to NuGet packages

It would be nice to be able to step inside Roslyn code when using NuGet packages.

This is nice guide on how to do this:
http://blog.davidebbo.com/2011/04/easy-way-to-publish-nuget-packages-with.html

Develop csc/vbc override tasks for Microsoft.Net.Compilers NuPkg so that NuGet users of Roslyn can use Analyzers at build time (VS2013, or non-Windows)

Currently, compiler users (even on VS2013) can easily upgrade to Roslyn by referencing the https://www.nuget.org/packages/Microsoft.Net.Compilers NuPkg. If they are staying on C#5/VB11, then they can even get a reasonably cooperative IDE experience.

However, if Microsoft.Net.Compilers included csc/vbc MSBuild tasks, they could also start using Roslyn analyzers as soon as they got the compiler NuGet.

This may be meaningful for customers who are not yet ready to upgrade to VS2015, or also for some NuGet users on Mono/non-Windows. Though we should check on the xbuild support.

Duplicate diagnostic reports in unit tests

We are observing multiple cases in the StyleCopAnalyzers project where the unit tests are producing multiple reports for the same diagnostic. The behavior is reproducible (100% observed consistency for Beta 1 and Beta 2), but we have diagnostics where only particular inputs result in the behavior, suggesting that the problem is not within the diagnostic implementation itself. We believe the problem lies either in the unit test framework or in Roslyn itself.

This behavior is currently affecting the following diagnostics:

• SA1121 Use built-in type alias
• SA1304 Non-private readonly fields must begin with upper-case letter
• SA1600 Elements must be documented

The unit test framework we use is the one provided with a new Roslyn diagnostic project (created with Visual Studio 2015 Preview), converted to use async methods instead of synchronous methods.

It would be enormously helpful if someone could help track down the cause of this issue.

Lambdas omitting parameters

I often have the situation of functions taking a lambda-expression as a parameter which take a handful of parameters themselves. Something like this:

someFunction((foo, bar, thing, another) => ..);

Of course, delegates with many parameters are often an indicator of bad design, and should be avoided. But it's the same with fewer arguments.

A situation like the above get's quite painful if the lambda-body does not even need all those parameters (or is in extreme always returning the same, constant value). But still, the compiler requests me to find unique names for each of the parameters. This is a problem especially when renaming / adding variables "above" the anonymous function which do then interfere with the unused variables there.

Most of the time what I do today is something like this:

someFunction((_, foobar) => ..); //Using '_' as a variable name somewhere around is highly unlikely

someFunction((a, foobar) => ..); //Using short variable names elsewhere is highly unlikely

It also helps reading the code, because I can save a few characters (getting more 'good' code into a line) and make it obvious for readers which variables are important to me, making the code more understandable.

Of course this is somewhat limited, because my "placeholders" are really just ordinary names which must not reoccur. This might lead to something like (_, __, foobar, ___) => .. which starts to look ugly again.

I would like it to have _ (or just another special character, for backwards-compatibility) not usable for ordinary variable names and forbid it's actual usage inside the lambda-body. Therefore it could be used as a real placeholder, enabling something like this:

someFunction((_, _, foobar) => ..);

or even this:

someFunction((foo, _, bar) => bar.otherFunction((_) => foo));

Does this sound like a useful thing to you?

Inline Rename breaks if any open document has text unavailable

InlineRenameSession.InitializeOpenBuffers calls document.TryGetText instead of GetTextAsync.

If the DocumentState's textSource is a RecoverableTextAndVersion rather than a constant source, this won't return a text and will break the rename.

Typing into a document sets the text to a constant version, so this doesn't usually happen.

It consistently happens for me in a TextView with both C# and VB buffers from the same workspace (eg, my Markdown editor); unless all open Roslyn buffers either have had keystrokes or have the cursor (which triggers UpdateText fromGetOpenDocumentInCurrentContextWithChanges), it will fail in that method.

As an aside, I can't get rename to work anyway within VS; I need a Host workspace for IDocumentNavigationService (internal) to allow the rename, but I need a non-Host or the VS version of ITextUndoHistoryWorkspaceService will refuse to operate at all with my custom workspace class.
Ironically, rename works fine in custom hosts outside VS (VSEmbed), because I can skip the VS.LangServices layer entirely, except for IDocumentNavigationService to allow the rename

Recursive Debugger Crash

Here are my exact repro steps

1. Clone madskristensen/WebEssentials2015@d946b8b (the version of WE shouldn't matter at all, unless I manage to fix F12)

2. Run

3. Open a Markdown file containing a C# code block:

   ```C#
   int x = x = 0;
   ```
   

4. Set Break on unhandled exceptions

5. Select any identifier defined in the code block and press F12

6. Roslyn will throw an ArgumentException (the buffer is somehow getting a StaticTextContainer; I'll file that issue after I manage to debug it)

7. Load symbols for the top two stack frames (EditorFeatures.Text & VS.LangServices) from DotPeek

8. Launch a third copy of VS, set Break On Exceptions, and attach to the original (debugger) copy

9. Open either of the top two stack frames

10. The debugger will crash with a null reference in vsdebugeng.manimpl.dll

11. Close the exception dialog in the third copy

12. Watch it crash too

Method generic type parameters are out of parameter list scope for 'nameof' expression

[A(nameof(U))] // ok
class Test<U> {
  void M<T>(
    T t = default(T), // ok
    string s = nameof(T) // error CS0103: The name 'T' does not exist in the current context
  ) { }
}

class A : System.Attribute {
    public A(string s) { }
}

It compiles as expected in CTP4, but fails in current 'master'. Maybe related to #40.

Improve analysis capability for partial methods (C#)

using System.Diagnostics;

partial class Test
{
    partial void FooBar();
}

partial class Test
{
    public void Foo()
    {
        FooBar();
    }
}

When analyzing the FooBar(); invocation there is no way to find out that FooBar(); has no body.

method.PartialDefinitionPart == null and method.PartialImplementationPart == null

ATM I would expect that PartialDefinitionPart != null and PartialImplementationPart == null in the case above. It would be nice if there would be a flag to flag partial methods.

If that's all too c# specific a ICSharpSourceMethod interface would solve that issue.

Unable to compile constant declaration with self-referencing nameof expression

const string N = nameof(N);

Currently this code won't compile because of:

error CS0110: The evaluation of the constant value for 'C.N' involves a circular definition

But there is no actual circular reference in evaluation of constant value.
I'm expecting this code to compile fine and constant N to have value "N".

Support the `vararg` calling convention in C#

The Virtual Execution System defined in ECMA-335 defines a vararg calling convention for methods which is not accessible from C#. As mentioned by @jaredpar in issue #36, both of the following signatures incur memory allocations for the purpose of passing parameters, even if those parameters are value types:

WriteLine(params object[] args)
WriteLine(params IEnumerable<object> args)

For applications which are sensitive to memory allocations but still wish to provide API methods which take a variable number of arguments, I propose including the following feature in addition to the more "friendly" methods taking object[] or IEnumerable<object>.

WriteLine(params ArgIterator args)

A method containing a final params ArgIterator argument would be emitted using the vararg calling convention. Access to the arglist IL instruction is implicit via C# code which accesses this argument.

Completion appears for null-conditional operator against actual types

In VS 2015 CTP 5, typing:

Console?. (Will cause member completion to appear)
String?.Join( (Parameter completion appears)
String?.Split( (Parameter completion appears even though Split is not a static method)

In these two examples, the null conditional operator is used on actual types (not instances).
Completion shouldn't pop up in these cases so the developer knows something is wrong.

Introduce Local should look for naming patterns in ForEachStatementSyntax.Expression

class Program
{
    static void Main(string[] args)
    {
        foreach (var num in GetNumbers())
        {

        }
    }

    static IEnumerable<int> GetNumbers()
    {
        return new[] { 1, 2, 3 };
    }
}

Highlight "GetNumbers()" in the foreach statement and use Ctrl+. to get the light bulb. Invoke "Introduce Local". Observe that the new local is named "enumerable".

Since we have code to detect known patterns like "GetBlah", it would be nice if we could notice that the Expression of the ForEachStatementSyntax was an InvocationExpression and try to recognize that pattern.

Please provide the C# Specification in PDF instead of DOCX

When going to the C# spec download page, the file provided is a docx. I don't have office, so I need to upload that to google drive and convert to something else to read.

It is really not a big deal, but it would be nice of you to just published the file in PDF instead, which everyone can open anywhere.

Feature request: Async stream generators

Currenty C# supports pull based sequence generators.
As IObservable<T> and IObserver<T> are now in mscorlib and Rx is such a success not only in .NET but in other languages and runtimes why not to add to C# ability to easily create async push based stream generators.

It could look like this:

private async IObservable<string> GetData()
{ 
    var data = await MakeRequest();
    yield return data;
    yield return await MakeAnotherRequest();
}

It would complete language support in the matrix of generators:

	sync	async
single	T	Task<T>
multiple	IEnumerable<T>	IObservable<T>