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

[Umbrella] Readonly ref workitems #17287

Closed
77 of 78 tasks
VSadov opened this issue Feb 21, 2017 · 1 comment
Closed
77 of 78 tasks

[Umbrella] Readonly ref workitems #17287

VSadov opened this issue Feb 21, 2017 · 1 comment

Comments

@VSadov
Copy link
Member

VSadov commented Feb 21, 2017

Tracking bug of smaller work items:

  • turn this bug into a readme.md document for the feature.

  • syntax model parsing

    • more tests for syntax/parsing if necessary
    • operators: should they be able to return by ref readonly? currently parser fails.
  • binding right RefKind, some testing

    • in parameters
    • ref readonly parameters
    • ref readonly returns. (make sure RefKind is not lost to become "ref", properties must not have setters though")
  • public API and symbol display,

    • default symbol display in error messages
    • symbol display, possibly switch for "ref readonly"/"in"
    • public API for returns finalized
  • method body binding for parameters

    • in parameters can be read
    • diagnostics for readonly behavior
  • Invoking methods with “in” parameters

  • More optimal codegen for indirect reading of readonly fields

    • suppress copying when accessing readonly fields in "readonly ref" context
    • suppress copying when accessing readonly fields to invoke readonly struct methods
    • suppress copying when fetching a field off a readonly field typed as ordinary struct
    • introduce a PEVerify-Compat flag for suppressing the above optimizations where possible.
  • check the interop story

  • additional diagnostics for semantics of in parameters

    • combine with various stuff - paramarrays, out, pointers, this,
    • out/in attributes?
    • use in expressions - recursive use of in parameters, dynamic, vararg, (the table of expr contexts?)
    • enforce no capturing/spilling
  • flow analysis

    • regular scenarios
    • region flow analysis
  • OHI

    • updating signature comparers to understand new RefKind (enough?)
    • in and none are ambiguous at call sites.
  • Operators?

  • Ref return binding

    • validate safe to return rule
  • Lambda Inference (similar to out ?)

  • Metadata

  • Passing readonly fields as in

    • ensure that it works
    • Object/ValueType methods that are not overridden can be called
    • more readonly variables - iteration/using/query variables
  • Readonly structs

    • parsing
    • binding
  • Ref extension methods

    • parsing
    • binding
    • unconstrained receiver types (ref readonly allowed?)
    • Elvis operator in combination with ref/in extensions w/ structs/generics. (async too)
    • Should Nullable types (structs) be allowed?
  • Elvis operator on “readonly ref”

  • IDE support

    • keyword recommender should not interfere with typing
    • Enable simple scenarios, block scenarios that do not work
  • Debug EE. Is there any work?

  • Mop up

@VSadov
Copy link
Member Author

VSadov commented Sep 14, 2017

Remaining items are covered by individual bugs and testplan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants