Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed #18763 Compiler crash on bad code in the IDE #20903

Merged
merged 11 commits into from
Aug 1, 2017
Merged

Fixed #18763 Compiler crash on bad code in the IDE #20903

merged 11 commits into from
Aug 1, 2017

Conversation

brianhartung
Copy link
Contributor

(First time contributor)

Fixes #18763

Customer scenario
Visual Studio crashes when hovering over invalid code in IDE.

Bugs this fixes:
#18763

Workarounds, if any
None

Risk
Low

Performance impact
Low (additional null check, no new allocations)

Is this a regression from a previous update?
No

Root cause analysis:
In CSharpSemanticModel method AddUnwrappingErrorTypes an existing null check failed to consider a null value on a child member access inside the body of the protected block.

How was the bug found?
Customer Reported

@jaredpar

…wrappingErrorTypes to fix crashing behavior in Issue #18763
@Pilchie Pilchie added Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee. labels Jul 16, 2017
@Pilchie Pilchie requested a review from a team July 16, 2017 18:12
@agocke
Copy link
Member

agocke commented Jul 16, 2017

I'd expect a compiler unit test to be added to verify this change.

@agocke
Copy link
Member

agocke commented Jul 16, 2017

Specifically, I'd expect an additional test in src/Compilers/CSharp/Test/Symbol/Compilation/SemanticModelGetSemanticInfoTests.cs

@@ -1852,7 +1852,7 @@ private bool IsInTypeofExpression(int position)
private static void AddUnwrappingErrorTypes(ArrayBuilder<Symbol> builder, Symbol s)
{
var originalErrorSymbol = s.OriginalDefinition as ErrorTypeSymbol;
if ((object)originalErrorSymbol != null)
if ((object)originalErrorSymbol != null && originalErrorSymbol.CandidateSymbols != null)
Copy link
Member

Choose a reason for hiding this comment

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

ErrorTypeSymbol.CandidateSymbols should return ImmutableArray<Symbol>.Empty rather than default(ImmutableArray<Symbol>).

Copy link
Member

Choose a reason for hiding this comment

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

@cston are you making a comment about what this PR should do or that possibly ErrorTypeSymbol is the source of the bug? Can't tell from the comment.

Copy link
Member

@cston cston Jul 17, 2017

Choose a reason for hiding this comment

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

If ErrorTypeSymbol.CandidateSymbols is returning default(ImmutableArray<Symbol>), it seems like the bug is in ErrorTypeSymbol.

@brianhartung
Copy link
Contributor Author

brianhartung commented Jul 19, 2017

Ok, I think we might have narrowed in on the issue here. I haven't added any unit tests yet (not 100% sure what those would look like) but I was hoping to have someone eyeball this fix. I can get VS (15.3 Preview) to reliably crash without it. Looks like the crux of the issue is that GetSemanticSymbols expects to return an ImmutableArray<Symbol> but in this case because the "this" reference it's considering is not really valid, it ends up adding a null item in the returned array which causes an NRE later, hence the crash.

@cston
Copy link
Member

cston commented Jul 19, 2017

A test would probably look something like the following. Please ensure the test fails without your fix.

        [Fact]
        public void AttributeArgumentLambdaThis()
        {
            string source =
@"class C
{
    [X(() => this._Y)]
    public void Z()
    {
    }
}";
            var compilation = CreateStandardCompilation(source);
            var tree = compilation.SyntaxTrees[0];
            var model = compilation.GetSemanticModel(tree);
            var syntax = tree.GetCompilationUnitRoot().DescendantNodes().Single(n => n.Kind() == SyntaxKind.ThisExpression);
            var info = model.GetSemanticInfoSummary(syntax);
            Assert.Equal("...", info.Type.ToTestDisplayString());
        }

@@ -15213,5 +15213,24 @@ class K

Assert.False(semanticInfo.IsCompileTimeConstant);
}

[Fact]
Copy link
Member

Choose a reason for hiding this comment

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

Please add [WorkItem(18763, "https://github.com/dotnet/roslyn/issues/18763")]. (I should have included that originally.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No problem...I'll do that now. Btw, as requested I did verify that with my change all tests pass locally (including my new one) but if I revert the fix, I get the original NRE in this new test case (in the same spot that caused the crash). Being new to this, I'm not sure what the best way is to provide evidence, but attached is a screenshot of the expected failure case
attributeargumentlambdathistest_failed
.

Copy link
Member

Choose a reason for hiding this comment

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

@brianhartung No problem. For future reference, if you say the test failed without your change we usually take your word on it :)

@cston
Copy link
Member

cston commented Jul 19, 2017

LGTM

@dpoeschl
Copy link
Contributor

dpoeschl commented Jul 19, 2017

retest windows_debug_vs-integration_prtest please
Reason: AppDomainUnloadedException

@jcouv jcouv merged commit fc73d57 into dotnet:master Aug 1, 2017
333fred added a commit to 333fred/roslyn that referenced this pull request Aug 4, 2017
…sion-expression-rewrite

* dotnet/features/ioperation: (229 commits)
  Adding Ioperation tests for WhileUntilLoopStatement (dotnet#21047)
  marked assert that needs to be re-enabled
  addressing more PR feedbacks
  PR feedback
  Remove InvocationReasons enum boxing
  PR feedbacks
  Expose if a Binary/Unary operator was 'Lifted' at the IExpression level. (dotnet#14779)
  addressing PR feedback
  added comments
  Update VS Integration machines to 15.3 Preview 6 (dotnet#21240)
  fixed typo
  Fixed dotnet#18763 Compiler crash on bad code in the IDE (dotnet#20903)
  Fix typo in ERR_RefReturnParameter2 (dotnet#21235)
  Fix unbound recursion with const var field in script (dotnet#21223)
  Typo fix (dotnet#20513)
  PR feedbacks and added some more tests
  When producing character literals, surrogate characters should be escaped. (dotnet#20720)
  Fix build correctness issues
  Fix possible null reference warnings
  Adding ioperation tests for ForEachStatement (dotnet#21048)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers cla-already-signed Community The pull request was submitted by a contributor who is not a Microsoft employee.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compiler crash on bad code in the IDE
8 participants