1. Don't include the newline itself in a line continuation construct.
This fixes generation of e.g. properties with embedded line
continuations.
2. Don't continue parsing strings past an unescaped newline (as naked
newlines are invalid inside strings). This avoids parsing the whole
remaining file as a string in case of broken input. It is both
useful to better support partly written files and to avoid loading a
whole malformed file in memory while reading it as a string.
See section 7.8.4 "String Literals" of ECMA-262:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
A regex is not a valid JavaScript property name, and the test case was
not meant to specifically check for handling of invalid syntax but
rather valid regex syntax with embedded quotes.
`let` is not yet part of the current ECMAScript standard but is part of
the ECMAScript 6 draft and is supported by Mozilla, and people already
use it in some contexts.
Also, the current ECMAScript standard marks `let` as a "considered
reserved word" (7.6.1.2), so it is already a reserved keyword in strict
mode.
See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let
Add support for implicit semicolons so many unterminated statements'
end are properly recognized.
The implementation doesn't follow the ECMAScript standard because doing
so requires to recognize precise grammar of all constructs, and the
parser doesn't currently work this way. So instead it uses some
heuristics that should work most of the time and only consider implicit
semicolons where they would be explicitly relevant to avoid most false-
positives. See the extensive comment in `readTokenFull()` for details.
In practice, this mostly fixes handling of files using unterminated
variable assignations like the following:
var v1 = 0
var v2 = 1
// ...
function f1() {
// ...
}
In such situations the parser used not to be able to really tell where
the variable assignation would end and would not recognize any
statement before the next semicolon or closing curly brace at the same
level. In practice, it wouldn't have emitted any tag for this example,
not even `v1` as it generates tags when reaching the statement's end.
Properly match open curly braces when parsing a statement not to
possibly get fooled by unexpected nested blocks, e.g. after a
`switch`'s `case` or a label.
This mostly reverts c54c3ad5e815d16e3b48f3c477465627808aadee and
replaces it with a more correct and complete solution.
Some highlights:
* Fixes handling of comments
* Adds support for attribute and namespace selectors
* Adds support for @supports blocks
* Fixes tag type for many selectors
* Adds support for pseudo-classes with arguments
There is no point in runner.sh depending on the generated Geany
executable, and this breaks running `make distcheck` before building
the sources, as the Geany executable doesn't exist yet.
Fix a race initialization leading to incorrect handling of preprocessor
directives on the first input line.
Test case contributed by Adam Hirst, thanks.
To do this we change the internal types to only use types matched by
symbols_get_current_scope(). This is a bit of a hack, but the tag
types were already questionable and simply mapped to ones the
TagManager know.
This however merges Functions and Subroutines under the same top-level
item in the symbol list.
Fortran 2003 allows '[' and ']' as array constructors in addition to
the legacy '(/' and '/)'. Fortran 2008 allows '[]' as part of a
CODIMENSION specifier, which can either be `codimension[]` in
the type-spec; or as either `variable[]` or `variable()[]` in
the entry-spec.
Credit to Colomban Wendling for the skipOverSquares logic, and
treating `codimension` as a special-case.
Last part of bug #1023.
Mitigate parse error with generics like `foo<X<Y> x;` by avoiding
matching past a semicolon (";") or open curly brace ("{"), which
can't be part of the generic. This isn't a proper fix, but mitigates
the impact of such constructs.
