- 14 3月, 2020 1 次提交
-
-
由 Charles Stoner 提交于
-
- 03 3月, 2020 1 次提交
-
-
由 Charles Stoner 提交于
-
- 29 1月, 2020 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 23 1月, 2020 1 次提交
-
-
由 Jonathon Marolf 提交于
-
- 18 12月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
* Refactor tuple implementation * Tweaks * Address PR feedback * Pass tuple data in constructors * Address more feedback * Tweak comparison * Restore constructWithTypeParameters flag to avoid overflow * Assert that tuple parameter matches TupleUnderlyingType somewhat * Rename to TupleData. Address some IDE feedback * Remaining TODO2's * Fix last IDE test! * Factor array comparison * Tweak WithTupleData and EqualsIgnoringTupleUnderlyingType * Expand a test * Remove duplicate line * Remove an EE test for badly formed ValueTuple type * PR feedback from Neal * Restore an IDE test without ValueTuple * Rename constants * Restore formatting
-
- 14 12月, 2019 1 次提交
-
-
由 Charles Stoner 提交于
-
- 10 12月, 2019 1 次提交
-
-
由 Charles Stoner 提交于
-
- 06 12月, 2019 1 次提交
-
-
由 Fredric Silberberg 提交于
-
- 29 10月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
-
- 18 9月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
Fixes #38469.
-
- 07 8月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
-
- 31 7月, 2019 2 次提交
-
-
由 Andy Gocke 提交于
Asking for Location.SourceTree may not produce a syntax tree, even if there is a backing syntax tree, because a speculative tree node may produce NoLocation when asked for one, even if there is a backing tree. This change stops us from trying to do the SyntaxTree->Location->SyntaxTree roundtrip because it's not guaranteed to succeed. Fixes #37454 (cherry picked from commit 83e8f8f0)
-
由 Andy Gocke 提交于
Asking for Location.SourceTree may not produce a syntax tree, even if there is a backing syntax tree, because a speculative tree node may produce NoLocation when asked for one, even if there is a backing tree. This change stops us from trying to do the SyntaxTree->Location->SyntaxTree roundtrip because it's not guaranteed to succeed. Fixes #37454
-
- 20 6月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
* Add optional [warnings | annotations] keyword to nullable directive * pragma warning <setting> nullable -> nullable <setting> warnings * Implement /nowarn:nullable
-
- 14 6月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
Remove support for explicit `object` generic type constraints
-
- 05 6月, 2019 1 次提交
-
-
由 AlekseyTs 提交于
Add initial support for 'notnull' generic type constraint. See https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-05-15.md Also fixes #36005.
-
- 06 4月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
Fixes #34678
-
- 15 3月, 2019 2 次提交
-
-
由 Julien Couvreur 提交于
-
由 AlekseyTs 提交于
-
- 13 3月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
-
- 11 3月, 2019 2 次提交
-
-
由 Jared Parsons 提交于
-
由 Jared Parsons 提交于
As a part of implementing nullable reference types many of our locals switched from `TypeSymbol` to `TypeSymbolWithAnnotations`. In the vast majority of cases this doesn't have a meaningful impact on compilation. They are bigger (about 3X) but it's still a relatively small `struct` (three words). The size difference is significant though in `BindNamespaceOrTypeOrAliasSymbol`. This method is used in recursive parts of binding and is mutually recursive with `BindQualifiedNam`. This method defines a large number of locals which contribute to every layer of recursion. When they moved to `TypeSymbolWithAnnotations` this pushed us outside our tolerance levels and we hit an overflow in extreme cases. Virtually none of these locals are used in the recursive case. Factored their use into local functions so we only pay the stack usage on demand. closes #33909 fixes https://github.com/dotnet/coreclr/issues/22757
-
- 09 3月, 2019 1 次提交
-
-
由 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
-
- 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.
-
- 09 2月, 2019 1 次提交
-
-
由 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.
-
- 04 2月, 2019 1 次提交
-
-
由 Andy Gocke 提交于
Adds a new "Preview" language version for C# that means the latest supported language version + the preview features available in the compiler. Also changes the "Default" (unspecified) language version to mean Preview, but provides a warning when preview features are used.
-
- 26 1月, 2019 1 次提交
-
-
由 Neal Gafter 提交于
Fixes #32290 Fixes #32169 Fixes #32141 Fixes #32025
-
- 11 1月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
Fixed a bug in constraint checking where the wrong Compilation would be used.
-
- 09 1月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
-
- 03 1月, 2019 1 次提交
-
-
由 Rikki Gibson 提交于
-
- 01 1月, 2019 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 21 12月, 2018 1 次提交
-
-
由 Neal Gafter 提交于
-
- 19 12月, 2018 1 次提交
-
-
由 Julien Couvreur 提交于
-
- 18 12月, 2018 1 次提交
-
-
由 Rikki Gibson 提交于
-
- 11 12月, 2018 1 次提交
-
-
由 AlekseyTs 提交于
Closes #30171. Closes #29838.
-
- 10 12月, 2018 2 次提交
-
-
由 dotnet-bot 提交于
-
由 dotnet-bot 提交于
-