src/fsharp/FSharp.LanguageService.Compiler/pppars.fsi

tests/fsharp/typecheck/sigs/*.dll

tests/fsharp/typecheck/sigs/*.exe

tests/fsharp/typeProviders/builtin/SqlDataConnection/DataDirectory/

tests/fsharp/typeProviders/builtin/SqlDataConnection/ExampleResolutionFolder/

tests/fsharp/typeProviders/builtin/SqlEntityConnection/DataDirectory/

vsintegration/src/unittests/Unittests.fsi

tests/fsharpqa/Source/CodeGen/EmittedIL/StaticInit/StaticInit_Module01.dll

tests/fsharpqa/Source/CodeGen/EmittedIL/StaticInit/StaticInit_Module01.pdb

New features are welcome, but be aware that Visual F# is a high-quality programming language with high-quality tools, and we wish to keep it that way. Before embarking on an extensive feature implementation, make a proposal in a GitHub issue or on the[F# Language UserVoice](https://fslang.uservoice.com/) so the community can review and comment on it.

When submitting issues, please use the following guidelines

- Suggestions for the F# Language and Core library should be added and reviewed at the[F# Language User Voice](https://fslang.uservoice.com/).

- Suggestions for the Visual F# Tools should be added and reviewed at the[Visual Studio F# Tools User Voice](https://visualstudio.uservoice.com/forums/121579-visual-studio/category/30935-languages-f-tools).

- New Bug Reports should always give accurate, clear steps for reproducing the bug, and all relevant details about versions, platform, etc. We suggest the following template:

Title: <a short, clear title>

Description: <adescriptionoftheproblem>

Repro Steps: <stepbystepdescription>

Expected: <whatisexpected>

Actual: <whatyoureallyget>

Severity: a description on how bad it is and why - is it blocking?

Version: Language, compiler, library, platform version

Link: Give a link to a ZIP, log files or other files if needed

Likely Cause: Link to the place in the code where things are likely going wrong, if possible

Workaround: List any known workarounds

###CLA

Contributors are required to sign a[Contribution License Agreement](https://cla.msopentech.com/) (CLA) before any pull requests will be considered. After submitting a request via the provided form, electronically sign the CLA when you receive the email containing the link to the document. This only needs to be done once for each Microsoft OSS project you contribute to.

All code submissions should be submitted with regression test cases, and will be subject to peer review by the community and Microsoft. The bar for contributions will be high. This will result in a higher-quality, more stable product.

- We expect contributors to be actively involved in quality assurance.

- We expect contributors to be actively involved in quality assurance.

- We expect contributors to be actively involved in quality assurance.

- Partial, incomplete, or poorly-tested contributions will not be accepted.

- Contributions may be put on hold according to stability, testing, and design-coherence requirements.

In addition to the above, "Code Cleanup" pull requests have the following minimum requirements:

- There must be no chance of a behavioural change, performance degradation or regression under any reasonable reading of the code in the context of the codebase as a whole.

- Code cleanup should generally be made separate to other checkins where possible, or the parts that are cleanup should be labelled as such.

- Code cleanup is much more likely to be accepted towards the start of a release cycle.

Performance improvement checkins have the following minimum requirements (in addition to the above)

- Performance tests and figures must be given, either in the PR or in the notes associated with the PR. PRs without performance figures will be closed with a polite request to please add them.

- The PR must show a reliable, substantive performance improvement that justifies the complexity introduced. For the compiler, performance improvements of~1% are of interest. For the core library, it will depend on the routine in question. For the Visual F# tools, reactivity of the user interface will be of more interest than raw CPU performance.

Bug fix PRs have the following minimum requirements

- There must be a separate tracking bug entry in the public GitHub issues. A link should be given in the PR. PRs without a matching bug link will be closed with a polite request to please add it.

- The code changes must be reasonably minimal and as low-churn, non-intrusive as possible. Cleanup should be done in separate PRs where possible (see above), and fixes should be as small as possible.

- Thorough test cases must be included in the PR (unless tests already exist for a failing case). PRs without matching tests will be closed with a polite request to please add the tests. However, if you need help adding tests, please note this in the description of the change and people will guide you through where to add the tests.

###Language Evolution

We are committed to carefully managing the evolution of the F# language.

###Coding guidelines

Although there is currently no strict set of coding or style guidelines, use common sense when contributing code - make an effort to use a similar style to nearby existing code. If you have a passion for helping us develop a set of coding guidelines that we can roll out and apply within this project, get involved and start a discussion issue.

Although there is currently no strict set of coding or style guidelines, use common sense when contributing code - make an effort to use a similar style to nearby existing code. If you have a passion for helping us develop a set of coding guidelines that we can roll out and apply within this project, get involved and start a discussion issue.