1. 05 8月, 2014 1 次提交
  2. 23 7月, 2014 1 次提交
  3. 18 7月, 2014 1 次提交
    • T
      Adjusting conditional branches for EnC. · b0615ac8
      TomasMatousek 提交于
      For every conditional branch that consumes a value of an expression that might contain calls to user code and that jumps across user code with sequence points, we need to store the value into a synthesized named local, emit stloc and ldloc and place a hidden sequence point on the ldloc instruction. Furthermore, the synthesized local variable has to be associated with the statement syntax whose lowering produces the conditional branch so that EnC infrastructure can map the local variable defined for the branch to the previous generation.
      
      In essence this is what’s going on:
      
      [|if (F())|]
      { … true … }
      else
      { … false … }
      
      IL:
      call F()
      stloc $value
      <-- hidden sequence point -->
      ldloc $value
      brfalse label_false
      <-- sequence point for “{“ of true-block -->
      … true …
      br label_end
      label_false:
      <-- sequence point for “{“of false-block -->
      … false …
      label_end:
      
      When the call to F() returns after an update has been performed on the caller the code execution continues in the old version of the caller body until a special remapping breakpoint is hit. These breakpoints are put on all sequence points of the method. If we didn’t put the hidden sequence point in front of the conditional branch the execution would continue in the old code until another sequence point is hit. Such a sequence point can be arbitrary (suppose e.g. that the else block of the if statement is deleted by an edit). The debugger only knows how to map IP of active statements in the old IL to an IP in the new IL, not arbitrary sequence points. By inserting the hidden sequence point we force the mapping to be performed at well-defined point that we can map to the new method body.
      
      The presence of the hidden sequence point then implies the need of storing the value of the if-statement condition to a long-lived local and reloading it back right after the sequence point. The store will happen before the IP is remapped and the load will happen in the new frame. The synthesized local must be allocated the same slot in the new frame so that its value is transferred from the old frame to the new frame.
      
      Fixes bug 927151: Edit and Continue breaks If statements while inside the conditional method.
      
      This change also includes an update to the test infrastructure to
      1) make it easier to update failing test that checks for an expected IL
      If a VerifyIL fails it synthesizes a temp file containing the unit test source and prints out a link that launches a diff tool (using ROSLYN_DIFFTOOL environment variable).
      2) to be able to directly test correspondence of sequence points to IL.
      VerifyIL has now an optional argument “sequencePoints”. When specified the printed IL will contain marks that designate presence of sequence points at IL offsets. “-“ for regular sequence point, “~” for hidden sequence points.
      I have updated some tests that are supposed to validate correspondence of sequence points to IL instructions to use this new format.  (changeset 1299447)
      b0615ac8
  4. 12 7月, 2014 1 次提交
    • T
      To support EnC well the compiler needs to carefully distinguish between... · d4b0a867
      TomasMatousek 提交于
      To support EnC well the compiler needs to carefully distinguish between long-lived and short-lived synthesized variables. Long-lived variables may cross sequence points and thus need to be mapped the the corresponding variables in the previous generation when emitting EnC deltas. Short-lived local variables shall never cross sequence points.
      
      This change revisits helpers that create synthesized variables and assigns each synthesized variable a SynthesizedLocalKind. Negative kind values are reserved for short-lived variables, positive values for long-lived variables.
      
      The change removed the option to give a synthesized variable an explicit name. The names of the variables are assigned at code-gen time based on their SynthesizedLocalKind. This is to enforce that the names of long-lived variables follow a naming pattern that allows use to reverse-engineer the SynthesizedLocalKind value from the variable name.
      
      Also renames DebugInformationKind.PDBOnly to DebugInformationKind.PdbOnly to follow .NET naming guidelines.
       (changeset 1293017)
      d4b0a867