Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge remote-tracking branch 'dotnet/master' into DefaultInterfaceImplementation #18687

Conversation

AlekseyTs
Copy link
Contributor

No description provided.

CyrusNajmabadi and others added 30 commits April 3, 2017 22:38
refactoring tests to not use extension methods
…onversion

Don't offer 'use throw expression' when there is an explicit cast in source.  It may change semantics.
…ameter

Overarching PR for features related to generating code starting from a parameter.
Simple script to automate the process of shipping our API files
natidea and others added 27 commits April 11, 2017 18:04
Move IOperation API entries back to PublicAPI.Unshipped.txt
Enable use of Sqlite in the OOP process and move our features over to using them.
…rtable

This change retargets the CSharpSymbolTest project from .NET 4.6 (which runs only on the desktop CLR) to netstandard 1.3 (which runs on both the Desktop 4.6 framework and CoreCLR).

These changes are necessary to enable more test coverage on CoreCLR, which will be especially impactful when we want to test language features which are only targeted to run on CoreCLR.

There are a lot of file changes in this PR but the most significant new code is in the TestExecutionContext, which is a new CoreCLR AppContext-based mechanism for running in-memory assemblies. This class is meant to have similar functionality to the existing desktop RuntimeEnvironment, but because AppDomains and AppContexts are incompatible, there are some substantial differences. Most notably, the TestExecutionContext views all assemblies next to the CoreCLR test runner (the "app base") as being shared among all test execution runs, including static variables. In contrast, the AppDomain runner only shares assemblies which are already loaded.

The second notable change is a rename from CreateCompilationWithMscorlib to CreateStandardCompilation. Despite the name, the most common usage of CreateCompilationWithMscorlib was just meant to create a simple compilation. The .NET Framework mscorlib was provided as a reference because it provided most of the common types our tests need to compile against, but it wasn't particularly important which types it supplied, beyond a minimum set.

Unfortunately, compiling against the .NET Framework mscorlib can introduce severe incompatibilities when trying to run the application on CoreCLR (which uses System.Runtime as its basis). This PR instead provides a new set of references (NETStandard.Library 2.0, the "standard" references) to try to provide as much compatibility as possible while also providing portability. Thus, the CreateCompilationWithMscorlib methods were renamed to CreateStandardCompilation to make it clear that no specific set of references is guaranteed when compiling against it. If that is desired, it's recommended to use the existing CreateCompilation methods to construct an explicit set of references to compile against (with all the implications that come from that).
…Completion

Provide completion that offers the explicit-interface-type when typing new members.
…r-20170412-070006

Merge dev15.2.x to master
@AlekseyTs AlekseyTs merged commit eac4136 into dotnet:features/DefaultInterfaceImplementation Apr 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.