Skip to content

Conversation

@iSazonov
Copy link
Collaborator

@iSazonov iSazonov commented Jul 3, 2020

PR Summary

Enable C# 9.0 features. Mainly to get is not for patterns like if (!(obj is null)) -> if(obj is not null)

PR Context

PR Checklist

@iSazonov iSazonov added the CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log label Jul 3, 2020
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a concern that a language feature in preview may not make to the official release, so what if we start to use a syntax in code and that feature is pulled out?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One feature I want is new is not. It is unbelievable that it will be removed.
Other new C# features are very specific and are not of interest at the moment. We will reject its till release in code reviews.
We already did this when Span appeared.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a valid concern, but the risk is low, especially if we're judicious about which features we use, as @iSazonov says. We're already taking .NET preview versions, and I'd say the risk of needing to roll those back is much greater.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as we can for a non-preview version of PowerShell ensure that we pin to a non-preview version of the C# language then I'd be happy with this change.

But it needs extra rigour to ensure that we don ship a 7.0.3 / 7.1.0 that uses preview language versions.

I expect most of that rigour is already in place, but still needed to be called out, just in case

Copy link
Collaborator

@rjmholt rjmholt Jul 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well we don't synchronise to C# language version releases like .NET releases, so we are forced to retain preview language versions for stable releases. When release time comes, pinning to a stable version would mean downgrading the version and changing all the code relying on the preview features we've been using to that point, which is bad for several reasons.

But I don't think it's uncommon to build a stable product on a preview language version, and unlike .NET preview releases, the language features all compile down to the same things. Using a preview C# version will affect the development, but is unlikely to affect the product.

I think the real risk is that a preview feature is taken out of the language because it doesn't meet some bar, at which point we'll need to go and change all the code that uses that feature in order to build again.

I'll add that it makes backporting harder theoretically, but so would just incrementing the language version to another stable version.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can gather, this is actually a moot discussion because C# 9 should stabilise with .NET 5. The only risk that remains then is that something we depend on in preview does not progress to stable. However, the risk here is identical to relying on a preview .NET API -- we would need to revert to using the old implementation if it happened.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification @rjmholt that makes a lot of sense :-)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've followed up with the .NET team on this to understand if our assumptions here can be relied on. I think until that's the case, it's fair for us to hold this PR

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I’ve confirmed that C# 9 is planned to stabilise with .NET 5 — so our only remaining concern is the tolerance of removed preview features

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Current plan is only modernizing our code with is not null feature. No plans exist to use other new features in near month or two before C# 9.0 will be stabilized.

@ghost ghost added Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept and removed Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept labels Jul 8, 2020
@iSazonov iSazonov changed the title Disable R2R for debug build and enable C# 9.0 features Enable C# 9.0 features Jul 9, 2020
@rjmholt
Copy link
Collaborator

rjmholt commented Jul 9, 2020

Looks like there's a test failure on Unix:

Describing Validate start of console host
Assemblies that are loaded but not expected: System.Reflection.Emit.dll
    [-] No new assemblies are loaded 20ms
      Expected exactly $null, but got @{InputObject=System.Reflection.Emit.dll; SideIndicator==>}.
      119:         $diffs | Should -BeExactly $null
      at <ScriptBlock>, /Users/runner/work/1/s/test/powershell/Host/Startup.Tests.ps1: line 119

I've rerun the tests, but they may fail again

@iSazonov iSazonov force-pushed the speedup-debug-compile branch from c9c152a to 334d363 Compare July 9, 2020 17:34
@iSazonov
Copy link
Collaborator Author

iSazonov commented Jul 9, 2020

Rebased... maybe resolve CI failures.


<TargetFramework>net5.0</TargetFramework>
<LangVersion>8.0</LangVersion>
<PublishReadyToRun>true</PublishReadyToRun>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be removed

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opps... Fixed.

@rjmholt
Copy link
Collaborator

rjmholt commented Jul 10, 2020

@iSazonov please resolve conflicts (I know they're because I merged the other PR...)

@rjmholt rjmholt requested a review from TravisEz13 July 10, 2020 17:28
@rjmholt
Copy link
Collaborator

rjmholt commented Jul 10, 2020

@TravisEz13 please re-review

@rjmholt rjmholt dismissed TravisEz13’s stale review July 14, 2020 20:49

Review has been addressed and is now outdated

@rjmholt rjmholt merged commit e88e8bd into PowerShell:master Jul 21, 2020
@iSazonov iSazonov deleted the speedup-debug-compile branch July 22, 2020 04:15
@iSazonov
Copy link
Collaborator Author

@xtqqczze If you want you could cleanup code (I will review) with var == null -> var is null, var != null -> var is not null (excluding UI.Internal and WinRM code).

@iSazonov iSazonov added this to the 7.1.0-preview.7 milestone Jul 22, 2020
@xtqqczze
Copy link
Contributor

xtqqczze commented Jul 23, 2020

@iSazonov Yes I can cleanup code. I will open seperate PR for var == null -> var is null as this is not C# 9 change.

This was referenced Jul 25, 2020
@TravisEz13 TravisEz13 modified the milestones: 7.1.0-preview.7, 7.1.0-preview.6 Aug 5, 2020
@ghost
Copy link

ghost commented Aug 17, 2020

🎉v7.1.0-preview.6 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants