-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #19648 from AlekseyTs/DefaultInterfaceImplementation
Merge 'dotnet/master' into DefaultInterfaceImplementation
- Loading branch information
Showing
580 changed files
with
22,170 additions
and
6,722 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,56 @@ | ||
| # Contributing to Roslyn | ||
|
|
||
| Guidelines for contributing to the Roslyn repo. | ||
|
|
||
| ## Submitting Pull Requests | ||
|
|
||
| - **DO** ensure submissions pass all Jenkins legs and are merge conflict free. | ||
| - **DO** follow the [.editorconfig](http://editorconfig.org/) settings for each directory. | ||
| - **DO** submit language feature requests as issues in the [C# language](https://github.com/dotnet/csharplang#discussion) / [VB language](https://github.com/dotnet/vblang) repos. Once a feature is championed and validated by LDM a developer will be assigned to help begin a prototype on this repo inside a feature branch. | ||
| - **DO NOT** submit language features as PRs to this repo first, or they will likely be declined. | ||
| - **DO** submit issues for other features. This facilitates discussion of a feature separately from its implementation, and increases the acceptance rates for pull requests. | ||
| - **DO NOT** submit large code formatting changes without discussing with the team first. | ||
|
|
||
| When you are ready to proceed with making a change, get set up to [build](https://github.com/dotnet/roslyn/blob/master/docs/contributing/Building%2C%20Debugging%2C%20and%20Testing%20on%20Windows.md) the code and familiarize yourself with our developer workflow. | ||
|
|
||
| These two blogs posts on contributing code to open source projects are good too: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and [Don’t “Push” Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik. | ||
|
|
||
| ## Creating Issues | ||
|
|
||
| - **DO** use a descriptive title that identifies the issue to be addressed or the requested feature. For example when describing an issue where the compiler is not behaving as expected, write your bug title in terms of what the compiler should do rather than what it is doing – “C# compiler should report CS1234 when Xyz is used in Abcd.” | ||
| - **DO** specify a detailed description of the issue or requested feature. | ||
| - **DO** provide the following for bug reports | ||
| - Describe the expected behavior and the actual behavior. If it is not self-evident such as in the case of a crash, provide an explanation for why the expected behavior is expected. | ||
| - Provide example code that reproduces the issue. | ||
| - Specify any relevant exception messages and stack traces. | ||
| - **DO** subscribe to notifications for the created issue in case there are any follow up questions. | ||
|
|
||
| ## Coding Style | ||
|
|
||
| The Roslyn project is a member of the [.NET Foundation](https://github.com/orgs/dotnet) and follow the same [developer guide](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md). The repo also includes [.editorconfig](http://editorconfig.org) files to help enforce this convention. Contributors should ensure they follow these guidelines when making submissions. | ||
|
|
||
| ### CSharp | ||
|
|
||
| - **DO** use the coding style outlined in the [.NET Foundation Coding Guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md) | ||
| - **DO** use plain code to validate parameters at public boundaries. Do not use Contracts or magic helpers. | ||
|
|
||
| ```csharp | ||
| if (argument == null) | ||
| { | ||
| throw new ArgumentNullException(nameof(argument)); | ||
| } | ||
| ``` | ||
|
|
||
| - **DO** use `Debug.Assert()` for checks not needed in retail builds. Always include a “message” string in your assert to identify failure conditions. Add assertions to document assumptions on non-local program state or parameter values, e.g. “At this point in parsing the scanner should have been advanced to a ‘.’ token by the caller”. | ||
| - **DO** avoid allocations in compiler hot paths: | ||
| - Avoid LINQ. | ||
| - Avoid using `foreach` over collections that do not have a `struct` enumerator. | ||
| - Consider using an object pool. There are many usages of object pools in the compiler to see an example. | ||
|
|
||
| ### Visual Basic Conventions | ||
|
|
||
| - **DO** apply the spirit of C# guidelines to Visual Basic when there are natural analogs. | ||
| - **DO** place all field declarations at the beginning of a type definition | ||
|
|
||
| ### Tips 'n' Tricks | ||
| Our team finds using [this enhanced source view](http://source.roslyn.io/) of Roslyn helpful when developing. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| # Async Task Main | ||
| ## [dotnet/csharplang proposal](https://github.com/dotnet/csharplang/blob/master/proposals/async-main.md) | ||
|
|
||
| ## Technical Details | ||
|
|
||
| * The compiler must recognize `Task` and `Task<int>` as valid entrypoint return types in addition to `void` and `int`. | ||
| * The compiler must allow `async` to be placed on a main method that returns a `Task` or a `Task<T>` (but not void). | ||
| * The compiler must generate a shim method `$EntrypointMain` that mimics the arguments of the user-defined main. | ||
| * `static async Task Main(...)` -> `static void $EntrypointMain(...)` | ||
| * `static async Task<int> Main(...)` -> `static int $EntrypointMain(...)` | ||
| * The parameters between the user-defined main and the generated main should match exactly. | ||
| * The body of the generated main should be `return Main(args...).GetAwaiter().GetResult();` |
Oops, something went wrong.