-
Notifications
You must be signed in to change notification settings - Fork 90
Incorporate v7 standard #956
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
Incorporate v7 standard #956
Conversation
Make sure evaluation order is described precisely in deconstructing assignments.
Co-authored-by: Bill Wagner <[email protected]>
…ithub.com/dotnet/csharpstandard into Mads-v7-local-declarations-in-expressions
…otnet#678) - They're still present in the grammar, and in explanatory paragraphs after relevant grammar sections. - There are references in Annexes B and D, but that feels reasonable. Fixes dotnet#676.
* Update v7-feature-tracker.md * Update v7-feature-tracker.md * Update v7-feature-tracker.md Reflects progress made during the Jan and Feb meetings.
* Update classes.md * Tweak the recently added description of unmanaged constraint Describe what happens when a type called `unmanaged` exists in the scope of an unmanaged constraint. * Update standard/classes.md * Update standard/classes.md * Update standard/classes.md * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> Co-authored-by: Jon Skeet <[email protected]> * Apply suggestions from code review * Update foreword.md Remove V6-specific entries, and add first new V7 items. * add unmanaged to list of contextual keywords --------- Co-authored-by: Bill Wagner <[email protected]> Co-authored-by: Nigel-Ecma <[email protected]> Co-authored-by: Jon Skeet <[email protected]>
Co-authored-by: RexJaeschke <[email protected]>
* fix internal references Over time, a few links in this clause were going to the wrong section. Update them to refer to the correct location. I went by the text surrounding the link. These were obviously wrong. * one more (questionable) link fix The text link says "unmanaged types", but the target is "pointer types". From both the context and the description in this paragraph, I think "unmanaged types" is a better target. However, this link has been to "pointer types" since C# 4.0 (or older). This one might be better left as is.
Co-authored-by: RexJaeschke <[email protected]>
…lement "missing" examples
Deconstructing assignment is now fully integrated into simple assignment, and doesn't have its own section. Deconstruction itself has been broken into an independent subsection of Expressions in anticipation of more deconstruction to come in future releases. The evaluation order of a deconstructing assignment is now elegant and recursive. However, it still does not match the compiler behavior 100%. The evaluation order of the expressions directly occurring in the assignment expression is correct (except for what seems to be a compiler bug in a very specific case). However, in the case of nested left side tuples, some conversions and deconstructions may occur slightly later than my text implies. I've chosen to live with this difference since it is small, unobservable when the conversions and deconstructions are side-effect free (as they should be), and frankly beyond my capabilities to adequately overcome.
* Handle pattern variables in declaration spaces Handle pattern variables and a few forgotten contexts for expression variables in declaration spaces. * Fix exception variables Fix the description of how exception variables are introduced. * Update standard/statements.md Co-authored-by: Bill Wagner <[email protected]> --------- Co-authored-by: Bill Wagner <[email protected]>
`unsafe` and ref returns are allowed for delegates, local functions, and methods. Update the grammar for that part. Fixes dotnet#886 See dotnet#941 (review)
This change from dotnet#941 should be made in 7.3
First commit: Fix the issue raised in the description of dotnet#894: If a method takes an `in` parameter of a struct type that is not a `readonly struct`, then the compiler must create a temporary to invoke a non-readonly member of that type.
Co-authored-by: jskeet <[email protected]>
…idy up. This clause has evolved over time as first implicitly typed, and now in v7 ref locals, have been introduced; the result ending up as something worthy of Heath Robinson or Professor Branestawm ;-) The result alas is also not entirely correct, the initial version was (almost), but subsequent kinds of local variables don't follow exactly the same rules... As a simple example of what ended up going wrong is the assertion: > A local variable declaration that declares multiple variables is equivalent to multiple declarations of single variables with the same type and *ref_kind*. and its associated example. This was (almost) correct originally, but is not correct for implicitly typed or ref local declarations where the initialization cannot be split from the declaration. (It was “almost” is it didn't allow for *for_initializer* or *resource_acqusition* cases where such a split is not possible either.) The rework divides local variable declarations into three subgroups, there really are four but we can get away with three (whether we should can be debated). These groups are directly represented in the reworked grammar, which also replaces a lot of conditional English prose. The clause starts with the general rules and then has a section for each subgroup detailing just the rules that apply in that case. The changes have been kept to the §13.6.2 clause; there are related issues in at least §7.7.1 Scopes:General and §13.14 The using statement – neither of these for example define the scope of a variable introduced in a *resource_acqusition*. Such issues are left for future (pre-v8) work!
… by *foreach_statement*. This may point to a revision being required there but it has just been added to §13.9.5 where it is used. So this PR now impacts 2 clauses…
…dealing with thge linkages between them. In particular: - The term *declarator* has been turned into the defined term ***declarator*** thus allowing other clauses which used to refer to *local_variable_declarator* to use it instead and simplify language at the same time. - The wording of the scope of a `for` variable has been made consisent between Statements & Basic Concepts – just word smithing using a blending of the two, no change in semantics. - The production *local_variable_type* has been moved from `foreach` to the textually earlier declaration expression, just seems more logical. I'll now remove the "draft" status of the PR, go at it folks!
Co-authored-by: Jon Skeet <[email protected]>
Co-authored-by: jskeet <[email protected]>
- Update the maximum line length to 81 (which appears to be okay) - Update the front page template version to 7
We always want the output to be in UTF-8.
These are almost all just line breaks in either grammar or C# code
* Update v7-feature-tracker.md * Note branch name changes --------- Co-authored-by: Bill Wagner <[email protected]>
Leaving in draft status for now. |
@BillWagner You have me as a reviewer, but it's not clear to me what I should look at. |
Hi @RexJaeschke
It's mostly to make a sanity check to see if all of V7 is in this PR. It's one merge commit, so if git did the right thing, we're fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took the time to browse all the changes and I'll mark this ready.
@RexJaeschke Can you check my one comment? There are a lot of diffs for the v8-tracker, and I don't know which branch had the correct and latest updates.
Once you help me get the right version of the tracker, I'll merge this and start working on rebasing the PRs.
Merge the
standard-v7
branch intodraft-v8
.