If we generated methods, properties or class children tags for a
variable, generate a class tag for the variable itself so the children
aren't orphaned.
If a property value had more than one token, the parser choked on it
and failed to parse further properties of the object. Fix that by
properly skipping the property's value. If that value is a sub-object,
parse it recursively.
Closes#3470609.
If an `if` haven't had braces, the code used to check itself for an
`else` after it, eating the next token if it wasn't actually an `else`.
So, drop the check for the else altogether since parseLine() handles
`else`s by calling parseIf() anyway.
This fixes constructs like:
if (foo)
bar();
function baz() {
// ...
}
Closes#3568542.
This makes `Foo.bar = function()` properly report a function tag "bar"
with scope "Foo" rather than a function tag "Foo.bar" with no scope.
Part of #3570192.
There is no need to set the token position information in the loop
searching for the initial token character, simply do that when we
finally found the token start.
The external declaration of "File" in read.h (defined in read.c) was
improperly tagged as "const" for it not to be modifiable outside of
read.c. Although it is good to protect this global variable against
improper modification, the use of "const" here makes it perfectly valid
for the compiler to assume that the fields in this structure never
changes during runtime, thus allowing it to do optimizations on this
assumption. However, this assumption is wrong because this structure
actually gets modified by many read.c's functions, and thus possibly
lead to improper and unexpected behavior if the compiler sees a window
for optimizing fields access.
Moreover, protecting "File" as it was with the "const" type qualifier
required a hack to be able to include read.h in read.c since "const"
and non-"const" declarations conflicts.
Actually, at least the JavaScript parser did suffer of the issue,
because it calls getSourceLineNumber() macro (expanding to a direct
"File" member access) several times in one single function, making it
easy for the compilers to cache the value as an optimization. Both GCC
and CLang showed this behavior with optimization enabled. As a result,
the line numbers of JavaScript tags were often incorrect.
The SIGTERM handler called the standard exit callback which uses
functions that are illegal in signal handlers. Commented out as
a prelude to full removal if no use case can be made.
Geany performance suffered with a lot of error underlining visible.
Matthew Brush developed an improved implementation that was accepted
into Scintilla, this selects that implementation.
Finding the current function now better handles the case the current
line is after a function but outside its scope, and many other issues
the scope reporting had.
The code assumed that if both old and new fold levels were above the
minimal function fold level the function couldn't have been changed,
which is wrong if a function can appear both inside and outside another
fold level (e.g. inside or outside a class).
This makes symbols_get_current_function() more accurate by using TM
data even on a modified file if realtime tag parsing is enabled, thus
if the data has reasonable chances to be correct.
This prevents a crash if the VTE library we happen to load lacks a
symbol we need, which can happen e.g. if the user passed an improper
library to the --vte-lib command-line option or if the VTE library is
loadable but broken.
