Update SA1000 for target-typed new expressions

[nxtn]

No description provided.

[sharwell]

A few comments in the diff, plus a new InternalsVisibleTo line is needed in the AssemblyInfo.cs for StyleCop.Analyzers and StyleCop.Analyzers.CodeFixes.

[sharwell]

@NextTurn I added the full C# 9 test project to master so you can rebase this and just add the new feature.

[codecov]

Codecov Report

Merging #3187 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3187   +/-   ##
=======================================
  Coverage   97.12%   97.12%           
=======================================
  Files         837      838    +1     
  Lines      104737   104742    +5     
  Branches     3403     3403           
=======================================
+ Hits       101723   101728    +5     
  Misses       2099     2099           
  Partials      915      915           

[DamianSuess]

When is 1.2 going to be released? It's been over a year now and the bug with the rule, SA1000, is breaking our standards.

[sharwell]

@DamianSuess My recommendation is to use the latest 1.2 beta releases. Since this package is only a development dependency, it doesn't cause NuGet to report warnings about the use of beta releases.

[DamianSuess]

@sharwell, thank you for the quick reply. I should have mentioned, in our case like some others, using NuGet packages labeled as "beta" is something we tend to avoid. In this case, we were able to allow it, however, it still raises eyebrows. Thank you again

[DRAirey1]

I don't use betas. Once bitten, twice shy. Please release 1.2.

[sharwell]

@DRAirey1 there are no plans in the immediate future to release a package without the beta suffix. While the beta suffix for a development-only dependency will not interfere with NuGet packaging, we do publish a second package for teams that have an unrelated policy against the versioning strategy used by this repository:
https://www.nuget.org/packages/StyleCop.Analyzers.Unstable/1.2.0.406

[jez9999]

@DRAirey1 there are no plans in the immediate future to release a package without the beta suffix. While the beta suffix for a development-only dependency will not interfere with NuGet packaging, we do publish a second package for teams that have an unrelated policy against the versioning strategy used by this repository: https://www.nuget.org/packages/StyleCop.Analyzers.Unstable/1.2.0.406

Why, out of interest? Is it particularly difficult to release a non-beta version?

[imuller]

Why not release a non-beta version? Don't understand it

[sharwell]

@imuller Releasing a non-beta right would be literally identical to releasing a beta version. Neither would have gone through the stabilization and manual validation processes that 1.0 and 1.1 went through. Since releasing a non-beta is literally identical to releasing a beta version, it means there would not be any meaningful difference for consumers and there is no need to rush out a non-beta package that changes the validation strategy. All consumers who would want (and accept) a non-beta package created from 1.2 at this point have already implicitly agreed that 1.2-beta is an acceptable package to use. 😄

[MartyIX]

@sharwell So can at least a beta be released? People seem tohit issues that have been fixed.

[sharwell]

Yep, hoping for this week.

[DRAirey1]

Releasing a non-beta right would be literally identical to releasing a beta version. Neither would have gone through the stabilization and manual validation processes that 1.0 and 1.1 went through.

That is absurdist logic. As consumers, there's a huge freaking difference between production and beta! You've been sitting on this issue for almost three years. Please fix it.

[sharwell]

@DRAirey1 The versioning policy is defined in the context of the authoring project, not the consuming project. I've tried to be transparent regarding the plans for release versions, but at this time I do not foresee a change being made. Versions 1.0 and 1.1 were rigorously audited to produce an exceptionally low likelihood of bugs in the context of the supported versions of C#, and I simply no longer have the time to perform a similar audit within the much shorter timeframe of C# language version updates coming from the Roslyn team. The current release approach aligns with policies defined by this project, the constraints of the distribution mechanism (NuGet), and accurately communicates the ongoing possibility of bugs in the support for newer language versions. Any remaining downstream policy incompatibilities would have been injected to the system by the consumer, so if there is an adoption issue my recommendation would be to request a policy exemption or update to account for the fact that NuGet does not enforce pre-release versioning constraints on compile-time package references marked PrivateAssets="all".

[ryan-carbon]

@sharwell the context provided on this pull request is super useful. How would you feel about updating the main readme to have a section on release cadence and versioning strategy, as this feels quite buried? Sorry in advance, if there is a section on this and I'm being blind!