1. 07 5月, 2019 1 次提交
  2. 04 5月, 2019 2 次提交
  3. 01 5月, 2019 1 次提交
  4. 27 3月, 2019 1 次提交
  5. 14 3月, 2019 1 次提交
  6. 13 3月, 2019 1 次提交
  7. 12 3月, 2019 1 次提交
  8. 09 3月, 2019 2 次提交
  9. 25 2月, 2019 1 次提交
    • N
      Revise NullableWalker to use a two-state solution · 6c329e3e
      Neal Gafter 提交于
      The NullableWalker is revised so that the inferred state of an expression is either `NotNull` or `MaybeNull` (represented by the new type `NullableFlowState`).  There is no longer such as thing as an oblivious rvalue.  There are four kinds of lvalues:
      - oblivious lvalues read as NotNull but null can be written to them
      - annotated lvalues read as MaybeNull and null can be written to them
      - unannotated lvalues read as NotNull and null may not be written to them
      - unconstrained type parameters read as MaybeNull but null may not be written to them
      
      In order to preserve the safety in the face of such unconstrained type parameters, we warn immediately when a null value of such a type is introduced.  This is a safety warning.  The contexts in which such a warning are given are
      - `default` and `default(T)`
      - `null` conversion to `T` (when `T` is known to be ref type)
      - `e?.M()` when the return type is `T`
      - dynamic conversion or cast to `T` when the dynamic might be null
      - explicit conversion to `T`
      - `e as T` when there is not an implicit conversion from the type of `e` to `T`
      - a call to a method like `FirstOrDefault()` that is annotated with `[MaybeNull] (not yet implemented)
      
      We remove the hidden diagnostics previously computed by the NullableWalker.
      
      We add debugger display support for a number of types used by the NullableWalker.  The display for `NullableWalker` summarizes the computed nullability of variables in a nice compact form.
      
      We remove support for definite assignment in the NullableWalker.  Some scenarios involving the use of not-definitely-assigned variables may cause cascaded diagnostics.  We might remove them in the future by initializing all vaiables to the `NotNull` state when they enter scope.
      
      We overhaul and simplify the inplementation of conversions, the null-conditional operator, and result inference for lifted operators.
      
      We simplify the Meet and Join operations so that they form a lattice on both the NullableAnnotation and NullableFlowState.
      
      Catch variables are now initialized to a non-null state on entry to the catch block.
      
      In unreachable code, every expression produces a non-null rvalue.  An erroneous expression produces a non-null rvalue (to suppress cascaded diagnostics).
      6c329e3e
  10. 30 1月, 2019 1 次提交
  11. 01 1月, 2019 1 次提交
  12. 19 12月, 2018 1 次提交
  13. 10 11月, 2018 1 次提交
    • A
      Remove NonNullTypes context and other unnecessary information stored in... · e63f3279
      AlekseyTs 提交于
      Remove NonNullTypes context and other unnecessary information stored in TypeSymbolWithAnnotations. (#30913)
      
      Remove NonNullTypes context and other unnecessary information stored in TypeSymbolWithAnnotations.
      
      Fixes #30845.
      
      Explicitly handle nullability analysis for unconstraint type parameters.
      
      Related to #29981, #29993
      e63f3279
  14. 30 10月, 2018 1 次提交
  15. 17 10月, 2018 1 次提交
  16. 07 9月, 2018 1 次提交
  17. 05 9月, 2018 1 次提交
  18. 01 9月, 2018 1 次提交
  19. 22 8月, 2018 1 次提交
  20. 03 8月, 2018 1 次提交
  21. 30 6月, 2018 1 次提交
  22. 12 6月, 2018 1 次提交
  23. 26 5月, 2018 1 次提交
  24. 09 3月, 2018 1 次提交
  25. 26 1月, 2018 1 次提交
  26. 04 10月, 2017 1 次提交
  27. 14 9月, 2017 1 次提交
  28. 13 9月, 2017 1 次提交
  29. 27 8月, 2017 1 次提交
  30. 16 8月, 2017 1 次提交
  31. 17 6月, 2017 1 次提交
  32. 24 5月, 2017 1 次提交
  33. 19 5月, 2017 1 次提交
  34. 13 4月, 2017 1 次提交
  35. 05 4月, 2017 1 次提交
  36. 29 3月, 2017 1 次提交
  37. 11 3月, 2017 2 次提交