TypeScript/tests/baselines/reference/parserModifierOnStatementInBlock2.errors.txt

tests/cases/conformance/parser/ecmascript5/ErrorRecovery/parserModifierOnStatementInBlock2.ts(2,4): error TS1184: Modifiers cannot appear here.


==== tests/cases/conformance/parser/ecmascript5/ErrorRecovery/parserModifierOnStatementInBlock2.ts (1 errors) ====
    {
       declare var x = this;
       ~~~~~~~
!!! error TS1184: Modifiers cannot appear here.
    }
Understand and handle modifiers on function declarations and variable statements within blocks. This ensures reusability for functions/variables that may have been outside a block, but end up inside one afterwards. It also ensure the same tree is produced when incremental parsing. i.e. if you have: declare function F() { } And you add a { above it, then we current have an incremental parsing bug. Namely we would see a FunctionDeclaration node and say 'yes, we can reuse that node while parsing the block'. This is currently broken because the normal parse would not have normally accepted such a node (because of the modifiers). This was an example of contextual parsing of the same kind of node. Something which we do not want to do if we want incremental parsing to work properly. 2014-12-11 03:52:56 +01:00			`tests/cases/conformance/parser/ecmascript5/ErrorRecovery/parserModifierOnStatementInBlock2.ts(2,4): error TS1184: Modifiers cannot appear here.`
Added error 'prologue' to each error baseline. 2014-09-12 22:35:07 +02:00

Understand and handle modifiers on function declarations and variable statements within blocks. This ensures reusability for functions/variables that may have been outside a block, but end up inside one afterwards. It also ensure the same tree is produced when incremental parsing. i.e. if you have: declare function F() { } And you add a { above it, then we current have an incremental parsing bug. Namely we would see a FunctionDeclaration node and say 'yes, we can reuse that node while parsing the block'. This is currently broken because the normal parse would not have normally accepted such a node (because of the modifiers). This was an example of contextual parsing of the same kind of node. Something which we do not want to do if we want incremental parsing to work properly. 2014-12-11 03:52:56 +01:00			`==== tests/cases/conformance/parser/ecmascript5/ErrorRecovery/parserModifierOnStatementInBlock2.ts (1 errors) ====`
Add snapshot of compiler sources 2014-07-13 01:04:16 +02:00			`{`
			`declare var x = this;`
			`~~~~~~~`
Understand and handle modifiers on function declarations and variable statements within blocks. This ensures reusability for functions/variables that may have been outside a block, but end up inside one afterwards. It also ensure the same tree is produced when incremental parsing. i.e. if you have: declare function F() { } And you add a { above it, then we current have an incremental parsing bug. Namely we would see a FunctionDeclaration node and say 'yes, we can reuse that node while parsing the block'. This is currently broken because the normal parse would not have normally accepted such a node (because of the modifiers). This was an example of contextual parsing of the same kind of node. Something which we do not want to do if we want incremental parsing to work properly. 2014-12-11 03:52:56 +01:00			`!!! error TS1184: Modifiers cannot appear here.`
Add snapshot of compiler sources 2014-07-13 01:04:16 +02:00			`}`