Regression for the triple start string issue has been introduced in SVN
revision 669 (fishman git a314e11158307db84c0dadb758846b2302fe69cd) on
2008-06-11. In ctags 5.7 it did work, in 5.8 not anymore.
See also http://sourceforge.net/p/ctags/bugs/229/ for the original bug,
which led to the old fix.
The other issue with normal strings in skipEverything() is even older.
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
Make go one of the builtin filetypes, add the parser and update the related
source and config files. While there, remove Rust from [Groups] in
filetype_extensions.conf because it's already a builtin filetype as well.
The parser itself is stolen from the fishman/ctags repo.
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.
