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

Merge dev15.6.x to master #24166

Merged
merged 17 commits into from
Jan 11, 2018
Merged

Conversation

dotnet-bot
Copy link
Collaborator

This is an automatically generated pull request from dev15.6.x into master.

git fetch --all
git checkout merges/dev15.6.x-to-master-20180111-080017
git reset --hard upstream/master
git merge upstream/dev15.6.x
# Fix merge conflicts
git commit
git push merges/dev15.6.x-to-master-20180111-080017 --force

Once all conflicts are resolved and all the tests pass, you are free to merge the pull request.

VSadov and others added 17 commits January 8, 2018 21:35
…rinsic. … (#24114)

* Arrays/pointers/nullables of intrinsic types are intrinsic. Type of array creations is apparent. Handle out vars.
This looks like simple oversight. The binder being used for type
parameters was retrieved from the binder factory since we didn't
explicitly pass one. For members this is correct since the binder
factory can be queried for top-level binders. This is not correct for
local functions because they use method body binders, which are not
accessible from the binder factory.

Mostly, this doesn't matter. The exception is when you try to
speculatively bind an attribute on a type parameter. Here, you need an
in-method binder and VS will crash if it's the wrong binder. This was
uncommon since attributes on type parameters are not permitted in local
functions, but VS should not crash.

Fixes #17814
* Make sure 'in' is honored in cref parsers/completion lists

* Clean up

* PR Comments

* Document API breaking change
The argument that stands for the receiver of a `ref` extension method must be always passed as `ref`
The LDM has decided that the following rules should be in effect when
calculating definite assignment for local functions:

  1. The entry point to a local function is always reachable.
  2. Variables captured in local functions are definitely assigned if
  they are definitely assigned in all branches into the local function.

It turns out these rules were almost exactly what the compiler already
implemented, but there was a bug in captured variable detection that
meant that variables captured in lambdas within local functions were
sometimes not counted as captured. This change fixes the bug around
capturing, which should cause the compiler to conform to this
specification.

Fixes #17829
@dotnet-bot dotnet-bot requested review from a team as code owners January 11, 2018 08:00
@VSadov VSadov merged commit 8cc0312 into master Jan 11, 2018
@VSadov VSadov deleted the merges/dev15.6.x-to-master-20180111-080017 branch January 11, 2018 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants