`final` is not a normal keyword, as it only have a special meaning in
some specific context. So, use a special case instead of a keyword not
to break identifiers of that name.
If there was two hashes (#) in an inline comment, only the content
between the two was considered a comment.
X-Universal-CTags-Commit-ID: ee93f5b9f393e76a850cf8c894cc748a62981156
See http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf 6.4.6§3.
Note: This is not exactly the upstream Universal CTags commit because
it depends on another change for adding the `enter` label, which was
then included here.
X-Universal-CTags-Commit-ID: 3b3b60c7664a321a31ec87de336fc6bda90c405e
The previous fix, coming from [CTags bug #1988026], was incorrect if
the parent was not a root-level element, as it checked the level name
(unqualified) against the parent name (qualified).
However, there is no need to check the level name, all what counts is
the indentation level itself: if it's smaller than an existing level,
it ends it.
This fixes [CTags bug #356].
[CTags bug #1988026]: https://sourceforge.net/p/ctags/bugs/227/
[CTags bug #356]: https://sourceforge.net/p/ctags/bugs/356/
X-Universal-CTags-Commit-ID: ab91e6e1ae84b80870a1e8712fc7f3133e4b5542
Unfortunately varType is Geany-only so this patch cannot be ported to ctags.
The removal of the extra { read is not the most elegant thing but making
skipType() aware of the argList collection complicates things too much.
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
