- 28 4月, 2016 40 次提交
-
-
由 Julien 提交于
Tuples: adding feature flag
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
NOTE: the spec reflects the feature as it is being implemented. It will definitely change in response to design changes as they are being implemented. The format is also likely to change to make it more spec-like. For starters it is just a loosely ordered list of feature descriptions.
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
(Literal, Lambda, InterpolatedString) They do not have "Expression" at the end.
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
Tuples: lookup well-known ValueTuple members relative to given underlying type (not well-known type)
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 vsadov 提交于
Made tuple ctors WellKnown members Made ctors optional in the bound tuple creation nodes ObsoleteAttributeData for tuple wrappers returns null (at least for now)
-
由 Julien Couvreur 提交于
-
由 vsadov 提交于
Note: we have to conservatively assume that parenthesized expression could also be a tuple in progress.
-
由 Julien Couvreur 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 VSadov 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 Julien Couvreur 提交于
-
由 vsadov 提交于
-
由 vsadov 提交于
Rebased onto future branch Fixed Tuple field signatures Fixed tests affected by tuple parsing
-
由 VSadov 提交于
Most interesting parts here are: * the syntax node shape and naming - these are public APIs so we should get the naming right. NOTE: I expect some churn here so for now I have disabled the public API diagnostics. * parsing something that starts with "(" is tricky since that can be a start of many constructs - lambdas, casts, parenthesized expressions... I have updated the lookahead logic that tries to figure what we are dealing with, but it may need some tuning to be more robust. In particular there could be some error recovery work to see that handling of broken code is sensible. ==== Current assumptions: 1) TupleTypes and TupleExpressions must have 2 or more elements/arguments. However we may have to parse 0 and 1 sized expressions for error recovery reasons. Those are syntax errors. 2) TupleType looks like (int x, int y) x = ... I.E. ( type [name], type [name]) We may enforce that all or no elements have names. Not sure yet if that needs to be in parser or binder. 3) TupleExpression looks like var something = (x: foo(), y: bar); I.E. ( [name:] expr, [name:] expr) just like with the types we may want to enforce that all or none of the arguments have names. Not sure if that is a syntax or binding error. It is not a part of this change.
-
由 Jared Parsons 提交于
Local function testing: var and async
-
由 Neal Gafter 提交于
Merge "typeswitch" into future
-
由 Neal Gafter 提交于
-