- 07 5月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
* Add reproducer for #34872 * Fix bug and add test * WIP * Test similar scenario in VB * Add void check in ClassifyConversionFromType, update tuple tests * Cleanup
-
- 04 5月, 2019 2 次提交
-
-
由 Andy Gocke 提交于
Implements a design change where overrides are allowed to change the type of the member as long as there is an implicit nullable reference conversion from the overriding type to the overridden type according to the nullable variance rules. Fixes #23268 Fixes #30958
-
由 AlekseyTs 提交于
Closes #28834. Closes #30061.
-
- 02 5月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
* Permit stackalloc in nested contexts. (#28969) Fixes #26759
-
- 01 5月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
Fixes #29956 Also introduce a helper `TypeSymbol.IsVoidType()`
-
- 30 4月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
Make sure nullability mismatch in constraints specified in different partial declarations (types/methods) are properly detected and reported. (#35272) Make sure nullability mismatch in constraints specified in different partial declarations (types/methods) are properly detected and reported. Fixes #30229. Fixes #35179. Implements the following LDM decision: For partial types, the invariant matching from type inference and merging. A mismatch between two non-oblivious candidates produces an error. No warnings are produced. For partial methods, nullability has to match with exception for oblivious and we produce warnings. For the result, we use the implementation signature inside the implementation, and the declaration signature for the callers.
-
- 12 4月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
Fixes #34233
-
- 06 4月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
-
- 29 3月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
-
- 27 3月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
Track l-values in conditional operator Assignment to ref variable produces safety warnings
-
- 22 3月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
Fixes #30987
-
- 15 3月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
-
- 14 3月, 2019 1 次提交
-
-
由 Fredric Silberberg 提交于
-
- 13 3月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
e.g. `ReturnType`, `ElementType`, etc.
-
- 12 3月, 2019 1 次提交
-
-
由 Fredric Silberberg 提交于
-
- 09 3月, 2019 3 次提交
-
-
由 Neal Gafter 提交于
-
由 Neal Gafter 提交于
- Rename `TypeSymbolWithAnnotations` to `TypeWithAnnotations` - Rename its type field from `TypeSymbol` to `Type` - Fields of Symbols that are of type `TypeWithAnnotations` that are currently named `Type` would be renamed `TypeWithAnnotations` Fixes #33736
-
由 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
-
- 28 2月, 2019 2 次提交
-
-
由 Neal Gafter 提交于
-
由 Rikki Gibson 提交于
* Add reproducer for #33388 * Skip normalizing task types if binding attribute arguments * Use InAttributeArgument property * Add test where task-like normalization affects overload resolution * Update AttributeArgument_TaskLikeOverloadResolution test case * Add assert and remove apparently unused branch * Add back comparison of remaining parameter types with InAttributeArgument guard * Update comment on remaining parameter comparisons * Add comment describing why we don't normalize task types in attribute arguments
-
- 26 2月, 2019 1 次提交
-
-
由 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).
-
- 16 2月, 2019 2 次提交
-
-
由 Jared Parsons 提交于
-
由 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.
-
- 12 2月, 2019 1 次提交
-
-
由 Jared Parsons 提交于
-
- 09 2月, 2019 3 次提交
-
-
由 Jared Parsons 提交于
The work for generic `unmanaged struct` constraints ended up threading through the correct `Compilation` object in many of the cases where I was using `Compilation` to calculate whether or not nullability needed to be checked for constraints. Used that whenever possible.
-
由 Jared Parsons 提交于
This makes nullability an explicit parameter to constraint checking rather than inferring it from the `ConversionsBase` argument. The reason is that these really represent separate operations: checking nullability in conversions and validating nullability in constraint checking.
-
由 Jared Parsons 提交于
closes #32953
-
- 01 2月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 30 1月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 16 1月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
-
- 11 1月, 2019 2 次提交
-
-
由 Rikki Gibson 提交于
Fixed a bug in constraint checking where the wrong Compilation would be used.
-
由 Andy Gocke 提交于
* Add ITypeSymbol.IsUnmanagedType and ITypeSymbol.IsRefLikeType Fixes #30427 and #30426
-
- 10 1月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
Pattern-based 'await foreach' should find parameterless 'GetAsyncEnumerator' and 'MoveNextAsync' (#32184)
-
- 05 1月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
-
- 01 1月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 19 12月, 2018 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 11 12月, 2018 1 次提交
-
-
由 AlekseyTs 提交于
Closes #30171. Closes #29838.
-
- 10 12月, 2018 2 次提交
-
-
由 dotnet-bot 提交于
-
由 dotnet-bot 提交于
-