Skip to content

R
roslyn

lwm1986 / roslyn
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
R
roslyn

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 14 7月, 2017 3 次提交
  3. 11 7月, 2017 2 次提交
    • V
      dynamic case where we must leak · 893b1f3b
      由 vsadov 提交于
      893b1f3b
    • V
      Retaining temporary IL slots allocated for passing rvalues as lvalues for the... · 03d0ec83
      由 vsadov 提交于 
      Retaining temporary IL slots allocated for passing rvalues as lvalues for the duration of the whole encompassing expression.

Passing rvalues to "in" parameters require allocation of temporary IL slots.

```C#
var result M1(42).ToString();

 // where  M is declared as
ref readonly int M1(in int x) {...}

// needs to be emitted as:
int temp = 42;
var result M1(ref temp) .ToString();   // passed by reference
```

This pattern bring an issue of the lifetime of such temporaries. Note that `M1` can return its argument back by reference, so the variable must exist as long as the return variable exists. - longer then the call to M1 itself.

The situation where we would have to pass an rvalue by reference via a copy was possible before, but it was very rare, so the solution was to just "leak" the temp. I.E - do not release such temps back to the temp pool. This is not a good solution when the situation becomes more common.

In this change we introduce a mechanism that collects temps of this kind and keeps them as for the duration of the most encompassing expression.
We will use the same mechanism for the preexisting cases as well.

Why "encompassing expression" is a sufficient extent for the temps. Consider the following concerns -

1) It is not possible to store a result of a `ref readonly` call, so the temp does not need to be retained at block level. - we do not allow `ref readonly` locals in source.
2) Internally compiler can create long-lived `ref readonly` temps for the purpose of returning from exception regions. This is not causing a concern since rvalues are not returnable and can never be stored insuch refs.
3) We sometimes call struct methods on a temp, there is no concern with the life time of such temps since struct `this` it cannot be ref-returned.
4) Sometimes short-term ref temps become mapped to long-term temps as a result of async spilling. We do not need to handle that specially here since those already have appropriate life times when extracted into  block variables in lowering.
      03d0ec83
  5. 20 6月, 2017 2 次提交
  7. 17 6月, 2017 1 次提交
  9. 16 6月, 2017 1 次提交
    • A
      Better exclude local functions from region analysis (#20004) · b4d18a7d
      由 Andy Gocke 提交于 
      By design, when data flow analyzes local functions it does so devoid of
surrounding context and records possibly unassigned variables rather
than reporting a diagnostic. Thus, all captured variables are expected
to be marked unassigned during data flow analysis without reporting a
diagnostic.

However, reporting a diagnostic is not the only side effect of running
data flow analysis. By calling virtual methods data flow analysis
informs derived types of unassigned variables. While the diagnostic is
suppressed and recorded, currently the virtual method is still called.
This has negative consequences for region analysis, which considers
these calls as indications of variables flowing out of the given
region, which may not be the case for local functions.

This PR changes data flow analysis to only call the ReportUnassigned
virtual method if not inside a local function, excluding local functions
from all unassignment reporting.

Fixes #17165, #18347
      b4d18a7d
  11. 09 6月, 2017 2 次提交
  13. 08 6月, 2017 1 次提交
  15. 07 6月, 2017 1 次提交
  17. 06 6月, 2017 1 次提交
  19. 01 6月, 2017 2 次提交
  21. 31 5月, 2017 5 次提交
  23. 27 5月, 2017 2 次提交
  25. 26 5月, 2017 2 次提交
  27. 25 5月, 2017 3 次提交
  29. 24 5月, 2017 1 次提交
  31. 23 5月, 2017 4 次提交
  33. 22 5月, 2017 1 次提交
  35. 20 5月, 2017 2 次提交
  37. 19 5月, 2017 4 次提交