Skip to content

Fix conversion issues in null coalescing operator#60202

Merged
jcouv merged 3 commits intodotnet:mainfrom
jcouv:null-coalescing
Mar 22, 2022
Merged

Fix conversion issues in null coalescing operator#60202
jcouv merged 3 commits intodotnet:mainfrom
jcouv:null-coalescing

Conversation

@jcouv
Copy link
Member

@jcouv jcouv commented Mar 16, 2022

Fixes #60046 (the issue was that ApplyConversionIfNotIdentity didn't consider scenario with identity conversion on top of another conversion)
Fixes #60059 and fixes #58176 (the issue was that initial binding created a conversion from nullable type to result type, instead of from underlying type to result type)

@jcouv jcouv self-assigned this Mar 16, 2022
@ghost ghost added the Area-Compilers label Mar 16, 2022
@jcouv jcouv force-pushed the null-coalescing branch from 99347eb to 84d4009 Compare March 16, 2022 20:27
@jcouv jcouv force-pushed the null-coalescing branch from 84d4009 to 452852c Compare March 16, 2022 20:47
@jcouv jcouv marked this pull request as ready for review March 17, 2022 03:13
@jcouv jcouv requested a review from a team as a code owner March 17, 2022 03:13
if ((object)optRightType != null && optRightType.IsDynamic())
{
var leftPlaceholder = new BoundValuePlaceholder(leftOperand.Syntax, optLeftType).MakeCompilerGenerated();
var leftPlaceholder = new BoundValuePlaceholder(leftOperand.Syntax, optLeftType0).MakeCompilerGenerated();
Copy link
Member Author

Choose a reason for hiding this comment

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

📝 When the LHS of null-coalescing operator is a nullable value type, in the branch where LHS is not null, the lowering does .GetValueOrDefault before converting to the result type. See GetConvertedLeftForNullCoalescingOperator.
In the case of dynamic as result type, this mean we'll do (object)left.GetValueOrDefault, so the conversion here needs to be leftType0 -> object.

@jcouv jcouv requested a review from AlekseyTs March 17, 2022 03:19
@jcouv
Copy link
Member Author

jcouv commented Mar 17, 2022

@dotnet/roslyn-compiler for review. Thanks

// See comments in Binder.BindNullCoalescingOperator referring to GetConvertedLeftForNullCoalescingOperator for more details.

if (!TypeSymbol.Equals(rewrittenLeftType, rewrittenResultType, TypeCompareKind.ConsiderEverything2) && rewrittenLeftType.IsNullableType())
if (!TypeSymbol.Equals(rewrittenLeftType, rewrittenResultType, TypeCompareKind.ConsiderEverything) && rewrittenLeftType.IsNullableType())
Copy link
Contributor

@AlekseyTs AlekseyTs Mar 17, 2022

Choose a reason for hiding this comment

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

ConsiderEverything

What analysis was performed to make this change? If this is just a mechanical change, we should undo it because the point of using ConsiderEverything2 was to come back and think about what kind should actually be used. #Resolved

Copy link
Member Author

Choose a reason for hiding this comment

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

That is the point of ConsiderEverything2. I think ConsiderEverything is correct here but given this is not central to this PR, I'm reverting.

Copy link
Contributor

@AlekseyTs AlekseyTs Mar 18, 2022

Choose a reason for hiding this comment

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

That is the point of ConsiderEverything2. I think ConsiderEverything is correct here

This isn't that obvious to me. It looks like we are concerned about identity convertibility between the types here. In cases like that ignoring everything (nullable annotations, dynamic vs. object, custom modifiers, ...) feels more appropriate. Changes like this, usually, should be accompanied by tests proving that the used option is appropriate and necessary.

@AlekseyTs
Copy link
Contributor

Done with review pass (commit 1)

@jcouv jcouv requested a review from AlekseyTs March 18, 2022 00:26
@jcouv jcouv marked this pull request as draft March 18, 2022 17:41
@jcouv
Copy link
Member Author

jcouv commented Mar 18, 2022

Looking at other affected tests...

@jcouv jcouv marked this pull request as ready for review March 18, 2022 18:52
Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

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

LGTM (commit 3), assuming CI is passing

@jcouv
Copy link
Member Author

jcouv commented Mar 21, 2022

@dotnet/roslyn-compiler for second review. Thanks

@RikkiGibson RikkiGibson self-assigned this Mar 21, 2022
Copy link
Member

@RikkiGibson RikkiGibson left a comment

Choose a reason for hiding this comment

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

LGTM with some nits

// var x8 = new C() ?? (a: 1, c: 3); // C
Diagnostic(ErrorCode.WRN_TupleLiteralNameMismatch, "c: 3").WithArguments("c", "(int, int)").WithLocation(18, 36)
);
_ = comp.GetEmitDiagnostics();
Copy link
Member

Choose a reason for hiding this comment

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

Do we exercise this adequately already with the 'TestUsedAssemblies' leg?

";
var comp = CreateCompilation(source);
comp.VerifyDiagnostics();
_ = comp.GetEmitDiagnostics();
Copy link
Member

Choose a reason for hiding this comment

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

Do we need this check? If we do, should we verify what exactly the emit diagnostics are?

Copy link
Member Author

Choose a reason for hiding this comment

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

That check was throwing/asserting before. Technically, that check is now embedded in .VerifyDiagnostics() in the new branch, but I wanted to make it explicit in the tests to fix the issue.

";
var compilation = CreateCompilation(source, references: new[] { CSharpRef });
compilation.VerifyDiagnostics();
compilation.GetEmitDiagnostics();
Copy link
Member

Choose a reason for hiding this comment

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

Similarly: is this needed when we have the VerifyUsedAssemblies leg? And if we do need it, should we verify the set of diagnostics here? Same nit for the below calls to 'GetEmitDiagnostics'.

@jcouv
Copy link
Member Author

jcouv commented Mar 22, 2022

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@jcouv jcouv merged commit 739b868 into dotnet:main Mar 22, 2022
@jcouv jcouv deleted the null-coalescing branch March 22, 2022 04:10
@ghost ghost added this to the Next milestone Mar 22, 2022
333fred added a commit to 333fred/roslyn that referenced this pull request Mar 24, 2022
…red-members

* upstream/main: (50 commits)
  Fix top-level speculation (dotnet#60274)
  Skip CodeDefinitionWindows integration tests
  Avoid resizing array builder while get unaliased references (dotnet#60220)
  Fix our x86 test execution (dotnet#60323)
  [LSP] Don't adjust breakpoints when there are diagnostics in the document (dotnet#60334)
  Allow VS Mac to access a few options and a helper method (dotnet#60333)
  Add support for CheckedStatement for smart break line (dotnet#60308)
  Initialize MEF parts before switching to the UI thread (dotnet#60289)
  Don't offer convert to switch when an implicit cast is present (dotnet#60224)
  Fix
  Add basic TS LSP server (dotnet#59639)
  Fix issue when multiple different diagnostics share a single fixer
  Update dependencies from https://github.com/dotnet/arcade build 20220321.2 (dotnet#60315)
  Check for reference assembly before deciding which language to show (dotnet#60271)
  Fix XLF files that were manually edited
  Revert "Fix a typo and an inconsistency"
  Fix conversion issues in null coalescing operator (dotnet#60202)
  Fix type parameter scoping for local functions (dotnet#60098)
  Update SDK version in docs, etc. (dotnet#60299)
  Edit the breaking change doc for publishing on docs (dotnet#60260)
  ...
333fred added a commit that referenced this pull request Mar 25, 2022
* Create solution on the main thread in integration tests

* Close solution on the main thread in integration tests

* Use cached data for completion of unimported types

Even if it might be stale. the completion list would be computed with cached data and cache refresh would be done in background.

* Use cached data for completion of unimported extension methods

Even if it might be stale. the completion list would be computed with cached data and cache refresh would be done in background.

* Try to refresh import completion cache in the background whenever completion is triggered

* Use AsyncBatchingWorkQueue for background cache updates

* Fix tests

* clean up

* Fix tests

* Make sure background task to update cache always run

* Expose ForceExpandedCompletionIndexCreation option to O#

This can be used to tweak test behavior to make it deterministic

* Don't use Workspace.CurrentSolution when refreshing cache in background

* Use AsynchronousOperationListener for background workqueues

* Update src/Tools/ExternalAccess/OmniSharp/Completion/OmniSharpCompletionOptions.cs

Co-authored-by: Sam Harwell <sam@tunnelvisionlabs.com>

* Pass ThreadingContext.DisposalToken to workqueue for cache refresh

* Remove namespace imports

* Remove enableRoslynAnalyzers from codespace default settings

Follow up to #60165

We don't think this is the right default as users probably don't want this unless they have at least 8 cores.

* Fix typo in Apply_namespace_matches_folder_preferences

* Remove period at the end to be consistent with other messages

* Fix inconsistency in other languages too

* Refactoring

* Ban incompatible service provider extension methods

* Assert window title before closing

* Remove outdated comment (#60275)

* Don't block on clearing the output window on the UI thread when generating a file (#60281)

* Fix issue with remove-unnecessary-cast and necessary explicit casts.

* Fix work item

* Correct change ObjectCreationExpression to ImplictObjectCreationExpression for SmartBreakline (#60249)

* Fix the initializer adding scenario

* Fix the initializer removal scenario

* Add an Assertion in debug to help if future derive type is added

* Remove the check for NewKeyword

* Option to always use default symbol servers for GTD (#60053)

* pass the listener to the constructor

* Edit the breaking change doc for publishing on docs (#60260)

Co-authored-by: Rikki Gibson <rikkigibson@gmail.com>

* Update SDK version in docs, etc. (#60299)

* Fix type parameter scoping for local functions (#60098)

Co-authored-by: Youssef1313 <youssefvictor00@gmail.com>

* Fix conversion issues in null coalescing operator (#60202)

* Revert "Fix a typo and an inconsistency"

This reverts #60238

* Fix XLF files that were manually edited

* Check for reference assembly before deciding which language to show (#60271)

* Update dependencies from https://github.com/dotnet/arcade build 20220321.2 (#60315)

[main] Update dependencies from dotnet/arcade

* Fix issue when multiple different diagnostics share a single fixer

* Add basic TS LSP server (#59639)

* Add basic TS LSP server

* Add external access layer for TS

* Include text sync handlers

* Fix build error

* Switch to explicit interface impl

* Fix namespaces

* Remove testing string

* Fix

* Don't offer convert to switch when an implicit cast is present (#60224)

* Initialize MEF parts before switching to the UI thread (#60289)

* Add support for CheckedStatement for smart break line (#60308)

* Add support for CheckedStatement

* Address feedback

* Remove a not needed import

* Allow VS Mac to access a few options and a helper method (#60333)

* [LSP] Don't adjust breakpoints when there are diagnostics in the document (#60334)

* Fix our x86 test execution (#60323)

* Fix our x86 test execution

The transition to `dotnet test` seems to have broken our unit tests that
depend on executing on an x86 architecture. This fixes that by using the
`--arch` argument to the `dotnet test` execution.

This was made more general to facilitate our future arm64 work in this
area

* Disable test failing on x64

* fix the test

* Apply suggestions from code review

Co-authored-by: Sam Harwell <sam@tunnelvisionlabs.com>

* Disable test on spanish

* Test fixes

Co-authored-by: Sam Harwell <sam@tunnelvisionlabs.com>

* Avoid resizing array builder while get unaliased references (#60220)

This was being resized constantly after opening Orchard Core, allocating about 2 GB. The fact that is being called this many times appears to be another bug that I'm following up on.

* Skip CodeDefinitionWindows integration tests

* Fix top-level speculation (#60274)

Co-authored-by: Youssef Victor <youssefvictor00@gmail.com>

Co-authored-by: Sam Harwell <Sam.Harwell@microsoft.com>
Co-authored-by: gel@microsoft.com <gel@microsoft.com>
Co-authored-by: Gen Lu <genlu@users.noreply.github.com>
Co-authored-by: Sam Harwell <sam@tunnelvisionlabs.com>
Co-authored-by: Jonathon Marolf <jmarolf@users.noreply.github.com>
Co-authored-by: Daniel Chalmers <daniel.chalmers@outlook.com>
Co-authored-by: astroC86 <66444189+astroC86@users.noreply.github.com>
Co-authored-by: David Wengier <david.wengier@microsoft.com>
Co-authored-by: Cyrus Najmabadi <cyrusn@microsoft.com>
Co-authored-by: Shen Chen <Cosifne@users.noreply.github.com>
Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
Co-authored-by: msftbot[bot] <48340428+msftbot[bot]@users.noreply.github.com>
Co-authored-by: Bill Wagner <wiwagn@microsoft.com>
Co-authored-by: Rikki Gibson <rikkigibson@gmail.com>
Co-authored-by: Rikki Gibson <rigibson@microsoft.com>
Co-authored-by: Julien Couvreur <jcouv@users.noreply.github.com>
Co-authored-by: Youssef1313 <youssefvictor00@gmail.com>
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Joey Robichaud <jorobich@microsoft.com>
Co-authored-by: David Barbet <dabarbet@microsoft.com>
Co-authored-by: Jared Parsons <jaredpparsons@gmail.com>
Co-authored-by: David Kean <davkean@microsoft.com>
@allisonchou allisonchou modified the milestones: Next, 17.2.P3 Mar 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

4 participants