Consolidate unsafe-code grammar #233

RexJaeschke · 2021-03-13T11:05:19Z

This PR resolves #37, Proposal 6.

With the consolidation of the unsafe grammar in PR #233, this text is no longer needed.

Nigel-Ecma

The integration LGTM.

I've made some wordsmithing-only comments relating to repetition and consistency between clauses. These are not hills to die on.

Nigel-Ecma · 2021-05-04T23:46:41Z

standard/expressions.md

    ;
 ```

+*pointer_indirection_expression* is available only in unsafe code ([§23.6.2](unsafe-code.md#2362-pointer-indirection)). *addressof_expression* is available only in unsafe code([§23.6.5](unsafe-code.md#2365-the-address-of-operator)).


Wordsmithing suggestion to remove repetition as before:

pointer_indirection_expression (§23.6.2) and addressof_expression (§23.6.5) are available only in unsafe code (§23).

Nigel-Ecma · 2021-05-04T23:54:06Z

standard/statements.md

    ;
 ```
+*unsafe_statement* is defined in [§23.2](unsafe-code.md#232-unsafe-contexts). *fixed_statement* is defined in [§23.7](unsafe-code.md#237-the-fixed-statement).


This doesn't follow the same pattern as similar statements in expressions, and I'll make the same wordsmithing suggestion as before:

unsafe_statement (§23.2) and fixed_statement (§23.7) are only available in unsafe code (§23).

Nigel-Ecma · 2021-05-04T23:55:03Z

standard/expressions.md

    ;
 ```

+*pointer_member_access* is available only in unsafe code ([§23.6.3](unsafe-code.md#2363-pointer-member-access)). *pointer_element_access* is available only in unsafe code ([§23.6.4](unsafe-code.md#2364-pointer-element-access)).


To avoid repetition maybe this could be:

pointer_member_access (§23.6.3) and pointer_element_access (§23.6.4) are only available in unsafe code (§23).

(It is technically correct as is, this is just wordsmithing.)

Nigel-Ecma · 2021-05-05T00:05:57Z

standard/statements.md

    ;
 ```

+*stackalloc_initializer* is defined in [§23.9](unsafe-code.md#239-stack-allocation).


Back in expressions.md these statements followed a "is only available in unsafe code" pattern, here in statements.md this is the second to follow an "is define in" pattern which doesn't directly mention "unsafe code". I suggested a change to the first occurrence (in embedded_statement to remove repetition (as suggested in expressions.md as well) which also changed it to the "is only available in unsafe code" pattern.

If there is no particular reason to change the pattern I'd suggest consistency and follow the pattern adopted in expressions.md. I won't flag them all, I've done the first one and this second would be:

stackalloc_initializer (§23.9) is only available in unsafe code (§23).

If there is a good reason to change the pattern that keep it but I'd suggest removing any repetition as suggested above for embedded_statement.

All this is wordsmithing, the text is technically correct.

Nigel-Ecma · 2021-05-05T00:08:40Z

standard/structs.md

    ;
 ```

+*unsafe_modifier* is defined in [§23.2](unsafe-code.md#232-unsafe-contexts).


Another case of the "x is defined in §clause" pattern as opposed to "x (§clause) is only available in unsafe code[§23]" one.

Nigel-Ecma · 2021-05-05T00:09:00Z

standard/structs.md

    ;
 ```

+*fixed_size_buffer_declaration* is defined in [§23.8.2](unsafe-code.md#2382-fixed-size-buffer-declarations).


Another case of the "x is defined in §clause" pattern as opposed to "x (§clause) is only available in unsafe code[§23]" one.

Nigel-Ecma · 2021-05-05T00:12:44Z

standard/types.md

    ;
 ```

-A third category of types, pointers, is available only in unsafe code [§23.3](unsafe-code.md#233-pointer-types).
+*pointer_type* is available only in unsafe code ([§23.3](unsafe-code.md#233-pointer-types)).


Following previous wordsmithing suggestions, maybe:

pointer_type (§23.3) is available only in unsafe code (§23).

There is a similar case below for non_array_type and maybe others.

Nigel-Ecma · 2021-05-05T00:22:48Z

@RexJaeschke, @BillWagner, @sharwell – I've approved the PR but haven't checked the grammar does what we think it should as I'm still using standard Antlr as Sam's fork isn't working for me and I've yet to figure out what dumb thing I've done to break it!

RexJaeschke · 2021-05-13T18:34:57Z

Thanks @Nigel-Ecma. I fixed all those instances you pointed out plus all "is defined in" instances in classes.md and interfaces.md.

The definition of an unmanaged_type was moved to §9.8 by PR #233. However, the old, now duplicate, definition still resides in 23.3, “Pointer types.” That duplicate is being deleted. Also, an Example table does not render correctly; the table header is treated as run-on text to the previous line:

With the consolidation of the unsafe grammar in PR #233, this text is no longer needed.

* Update statements.md * Update unsafe-code.md * Add semantics and example for local functions v7.0 feature * removed local function unsafe grammar extension With the consolidation of the unsafe grammar in PR #233, this text is no longer needed. * include support for local functions * add support for local functions * fix build issues * Apply suggestions from code review Co-authored-by: KalleOlaviNiemitalo <[email protected]> * clarify definite assignment, add examples Addresses comments in committee meeting: - #104 (comment) - #104 (comment) * respond to feedback. * grammar updates * Incorporate Andy's text In this commit, create the new clause for the definite assignment rules for local functions. Move the existing example to that clause. Add text from Andy's comments and notes. * finish local functions and definite assignment. Incorporate the rules for definite assignment for captured variables in local functions. This is both for local function calls and for delegate conversion. * typo * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> * Apply suggestions from code review * Update standard/statements.md Co-authored-by: Jon Skeet <[email protected]> * Update standard/statements.md * Update standard/statements.md Co-authored-by: Neal Gafter <[email protected]> * Update standard/statements.md * Update standard/statements.md * edits based on September committee meeting * fix link text * fix section renumbering issue * Final edits We resolved these two discussions during the committee meeting. Edits reflect those decisions. * updates from code review. * one more bit of feedback. Co-authored-by: Bill Wagner <[email protected]> Co-authored-by: KalleOlaviNiemitalo <[email protected]> Co-authored-by: Nigel-Ecma <[email protected]> Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Neal Gafter <[email protected]>

The definition of an unmanaged_type was moved to §9.8 by PR dotnet/csharpstandard#233. However, the old, now duplicate, definition still resides in 23.3, “Pointer types.” That duplicate is being deleted. Also, an Example table does not render correctly; the table header is treated as run-on text to the previous line:

RexJaeschke added 8 commits March 13, 2021 05:24

Update types.md

347d286

Update expressions.md

d9ba657

Update statements.md

0b73b96

Update classes.md

f977673

Update structs.md

bcc857c

Update interfaces.md

5772ad0

Update delegates.md

c48b9dd

Update unsafe-code.md

9166f69

RexJaeschke added this to the C# 6 milestone Mar 13, 2021

RexJaeschke requested review from sharwell and Nigel-Ecma March 13, 2021 11:05

RexJaeschke mentioned this pull request Mar 13, 2021

ANTLR: Deciding on how far to go with this #37

Closed

RexJaeschke added a commit that referenced this pull request Apr 19, 2021

removed local function unsafe grammar extension

c86c9b0

With the consolidation of the unsafe grammar in PR #233, this text is no longer needed.

RexJaeschke mentioned this pull request May 4, 2021

Resolve numerous ANTLR issues #261

Merged

Nigel-Ecma approved these changes May 5, 2021

View reviewed changes

RexJaeschke added 7 commits May 13, 2021 13:51

Make consistent, wording re unsafe mode

33b1e58

Make consistent, wording re unsafe mode

4c6e078

Make consistent, wording re unsafe mode

bf851fe

Make consistent, wording re unsafe mode

f889492

Merge branch 'draft-v6' into Rex-consolidate-unsafe-code-grammar

46a1318

Make consistent, wording re unsafe mode

3aa9bc5

Make consistent, wording re unsafe mode

dafd429

RexJaeschke merged commit b2b17c6 into draft-v6 May 13, 2021

RexJaeschke deleted the Rex-consolidate-unsafe-code-grammar branch May 13, 2021 18:35

RexJaeschke mentioned this pull request Sep 19, 2021

Remove duplicate text and fix table format #376

Merged

BillWagner pushed a commit that referenced this pull request Apr 2, 2022

removed local function unsafe grammar extension

6fb41bb

With the consolidation of the unsafe grammar in PR #233, this text is no longer needed.

BillWagner pushed a commit that referenced this pull request Jun 15, 2022

removed local function unsafe grammar extension

472b8f7

With the consolidation of the unsafe grammar in PR #233, this text is no longer needed.

BillWagner pushed a commit that referenced this pull request Oct 2, 2022

removed local function unsafe grammar extension

202efa2

With the consolidation of the unsafe grammar in PR #233, this text is no longer needed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Consolidate unsafe-code grammar #233

Consolidate unsafe-code grammar #233

Uh oh!

RexJaeschke commented Mar 13, 2021

Uh oh!

Nigel-Ecma left a comment

Uh oh!

Nigel-Ecma May 4, 2021

Uh oh!

Nigel-Ecma May 4, 2021

Uh oh!

Nigel-Ecma May 4, 2021

Uh oh!

Nigel-Ecma May 5, 2021

Uh oh!

Nigel-Ecma May 5, 2021

Uh oh!

Nigel-Ecma May 5, 2021

Uh oh!

Nigel-Ecma May 5, 2021

Uh oh!

Nigel-Ecma commented May 5, 2021

Uh oh!

RexJaeschke commented May 13, 2021

Uh oh!

Uh oh!

Consolidate unsafe-code grammar #233

Consolidate unsafe-code grammar #233

Uh oh!

Conversation

RexJaeschke commented Mar 13, 2021

Uh oh!

Nigel-Ecma left a comment

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 4, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 4, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 4, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 5, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 5, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 5, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma May 5, 2021

Choose a reason for hiding this comment

Uh oh!

Nigel-Ecma commented May 5, 2021

Uh oh!

RexJaeschke commented May 13, 2021

Uh oh!

Uh oh!