- 14 3月, 2019 2 次提交
-
-
由 Chris Sienkiewicz 提交于
- Don't do analysis for speculative attributes - Manually call TryGetThisParameter, rather than MethodThisParameter which can throw
-
由 Chris Sienkiewicz 提交于
- Add an entry point to nullable walker for attribute analysis - Implement analyze attribute in the walker - Remove the analysis from binder_attributes and call nullable walker instead - Add extra fields to BoundAttribute that are needed for nullable analysis - Add some extra test scenarios
-
- 13 3月, 2019 1 次提交
-
-
由 Charles Stoner 提交于
-
- 12 3月, 2019 5 次提交
-
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Jared Parsons 提交于
Have to disable quiet restore explicitly on local dev machines when doing a bootstrap build to work around this arcade issue: https://github.com/dotnet/arcade/issues/2220
-
由 vsadov 提交于
-
由 Neal Gafter 提交于
* Implement LDM decisions on the behavior of `??` and `??=` operators Fixes #33743
-
- 09 3月, 2019 5 次提交
-
-
由 vsadov 提交于
Bases of Nullable are reference types and thus base methods are called via boxed values which wold NRE on nulls. Fixes:#33174
-
由 vsadov 提交于
-
由 vsadov 提交于
```cs S? x = <expr of Type S>; // works already S? x = new Nullable<S>(<expr of Type S>); // means the same as above and should work the same. ``` Fixes:#32626
-
由 Neal Gafter 提交于
* Eliminate unspeakable NullableAnnotation values. * Dynamic invocations result in an oblivious state Fixes #33638 * Fix up expected diagnostics Due to #33924 * Rename NullableAnnotation.Unknown to NullableAnnotation.Oblivious
-
由 Julien Couvreur 提交于
-
- 08 3月, 2019 4 次提交
-
-
由 Neal Gafter 提交于
Fixes #33905
-
由 Charles Stoner 提交于
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
The change to move nullable to a two state solution inadverntently changed how the CLR inlines a number of method calls. The combination of not-inlining and over-inlining caused us to have a much larger "frame" for analyzing a fluent call and exceeded our tolerance levels. This adjusts the inlining so that we get the same results as before. closes #33775
-
- 07 3月, 2019 2 次提交
-
-
由 Julien Couvreur 提交于
-
由 Neal Gafter 提交于
See also #28798, #32047, #33879 Closes #29953
-
- 01 3月, 2019 3 次提交
-
-
由 Charles Stoner 提交于
-
由 Andy Gocke 提交于
Reflects the changes described in https://github.com/dotnet/csharplang/pull/2214. Range now looks optimistically for some special members with optional parameters, but will fall back to the Range constructor if they aren't present. This change also removes all of the specialized codegen that was going on with arrays and strings in favor of expected helpers or real members.
-
由 Chris Sienkiewicz 提交于
* Nullability for NVT with no constructor argument: - Explicitly check if an object creation is a nullable value type - Set its state to nullable when it is the default constructor that is being called - Update tests
-
- 28 2月, 2019 4 次提交
-
-
由 Neal Gafter 提交于
-
由 Neal Gafter 提交于
-
由 Neal Gafter 提交于
-
由 Charles Stoner 提交于
-
- 26 2月, 2019 4 次提交
-
-
由 Neal Gafter 提交于
-
由 Neal Gafter 提交于
-
由 Jared Parsons 提交于
-
由 Neal Gafter 提交于
-
- 25 2月, 2019 1 次提交
-
-
由 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).
-
- 23 2月, 2019 3 次提交
-
-
由 Charles Stoner 提交于
-
由 Julien Couvreur 提交于
-
由 Charles Stoner 提交于
-
- 20 2月, 2019 2 次提交
-
-
由 Charles Stoner 提交于
-
由 Julien Couvreur 提交于
-
- 16 2月, 2019 2 次提交
-
-
由 Charles Stoner 提交于
-
由 Jared Parsons 提交于
Most nullability checking of tuple values should occur during the nullable walking phase. This is because the test relies on the inference of the values, not the explicit types in the code. The only time we need to validate tuple nullability constarints during initial binding is when we're binding a named type.
-
- 15 2月, 2019 2 次提交
-
-
由 Neal Gafter 提交于
- Fix parsing regression of expressions involving parens when used as a case expression or a constant pattern. Fixes #33054 Fixes #33208 - Incidentally also correct and test the precedence of the switch expression See https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#switch-expression for the spec. - Fix terminology to match the spec - "conditional expression" rather than "ternary expression".
-
由 Jared Parsons 提交于
-