- 10 5月, 2016 6 次提交
-
-
由 Jason Malinowski 提交于
This simplifies the test, and doesn't test the edge case where we have text buffers not backed by documents
-
由 Jason Malinowski 提交于
They can call the public entry point instead.
-
由 Jason Malinowski 提交于
-
由 Jason Malinowski 提交于
-
由 Jason Malinowski 提交于
-
由 Jason Malinowski 提交于
-
- 07 5月, 2016 1 次提交
-
-
由 Julien 提交于
-
- 06 5月, 2016 2 次提交
-
-
由 Julien 提交于
-
由 Dustin Campbell 提交于
-
- 05 5月, 2016 3 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 Manish Vasani 提交于
1. Split out the tests into ones with built-in IDE analyzers and ones with only third party analyzers 2. Tests depends on closed side changes (add/update VS tao actions)
-
由 Bart Koelman 提交于
-
- 04 5月, 2016 4 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 Matt Warren 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 03 5月, 2016 2 次提交
-
-
由 Heejae Chang 提交于
-
由 CyrusNajmabadi 提交于
-
- 30 4月, 2016 1 次提交
-
-
由 Matt Warren 提交于
-
- 29 4月, 2016 5 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 Jason Malinowski 提交于
-
由 CyrusNajmabadi 提交于
-
- 28 4月, 2016 5 次提交
-
-
由 VSadov 提交于
-
由 Julien 提交于
-
由 vsadov 提交于
Note: we have to conservatively assume that parenthesized expression could also be a tuple in progress.
-
由 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.
-
- 27 4月, 2016 3 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 Neal Gafter 提交于
-
由 David Poeschl 提交于
Fixes #10469
-
- 26 4月, 2016 1 次提交
-
-
由 Manish Vasani 提交于
-
- 25 4月, 2016 3 次提交
-
-
由 Manish Vasani 提交于
-
由 Manish Vasani 提交于
This reverts commit ffec6afc.
-
由 Neal Gafter 提交于
-
- 22 4月, 2016 4 次提交
-
-
由 CyrusNajmabadi 提交于
Only pass FixAllContexts to methods that actuall y need it. For internal methods that don't need all that functionality, pass a FixAllState instead.
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-