When allocation with g_malloc(), the memory should be freed using
g_free(), not plain free().
Also, use g_try_malloc() instead of g_malloc() where the code carefully
handles allocation failures itself.
tm_tags_find() relies on a sorted tags array to be passed in but in
tm_source_file_set_tag_arglist() we don't have a sorted array yet and
sorting it on demand seems more heavy than the alternative:
make tm_tags_find() search the array linear if the new flag is set.
This fixes a bug in the Python parser when assigning the argument list
of __init__() methods to their class' argument list which annoyed me
for years already.
Also add a test case for this.
Even though PHP doesn't handle those very well (it emits warnings about
"unexpected character"), it still counts them as whitespaces, so
properly handle them as such.
Cython allows the use NumPy arrays on a C level. In that context, a
typical return type declaration could be e.g. "cpdef
numpy.ndarray[dtype=double, ndim=1] name". This now generates a tag for
the function. Previously, the equal sign prevented that.
Bit-wise operation is inappropriate here because `c` might be negative,
since EOF is generally represented as -1. Since -1 is stored as all
bits at 1 on most common architectures, the test will evaluate to true,
hence entering an infinite loop.
Add a keyword for procedure pointers and treat declarations such as
'procedure(subprogram_to_point_to), pointer :: my_pointer' just like
declarations of a real or integer variable.
For some conditions static_assert was stopping further parsing.
For example:
static_assert(a<1,"too small");
would stop all further parsing. Now static_assert is recognised
and content of the parens is ignored.
js.c only allowed keywords 'function' 'Function' or 'Object' after
'new' but js syntax allows any constructor function:
var name = new constructor_function( args );
ie an identifier where js.c allowed only keywords.
So changed js.c to allow any identifier as well as the keywords.
Asciidoc overloads lines of dash (-) for heading underline and
open block delimiting (--). This made the parser recognise list
continuation blocks as headings. Now requires more than two
underline characters for a heading.
Instead of hand-parsing the argument list and possibly choking inside
comments, strings, heredoc, etc., use the normal token mechanism and
simply convert the tokens to a string representation as the argument
list. This technique might perhaps lead to some missing characters in
the argument list representation in the (unlikely) case a token
appearing in the argument list is reported as a generic type for which
it is impossible to know the correct string representation, but this
could always be fixed by adding a specific token type and is anyway
less problematic than maybe breaking further parsing of the document.
PHP namespaces don't work anything like a block, so the implementation
is specific and not combined with scope management. Namespaces cannot
be nested, and they may apply either to the rest of the file (until the
next namespace declaration, if any) or to a specific block.
Namespaces applying to the rest of the file:
namespace Foo;
/* code in namespace Foo */
namespace Bar\Baz;
/* code in namespace Bar\Baz */
Namespaces applying to blocks:
namespace Foo {
/* code in namespace Foo */
}
namespace Bar\Baz {
/* code in namespace Bar\Baz */
}
namespace {
/* code in root namespace */
}
Only generate tags for variable declarations without assignments inside
classes and interfaces not to get fooled by rvalues.
This prevents generation of a "$bar" tag for something like:
$foo = $bar;
while still generating "$bar" tag for:
class Foo {
var $bar;
}
Fix parsing of functions declarations with a leading ampersand (&),
used to make the function return a reference:
function &foo($arg1, $arg2) {
/* ... */
}
Rewrite the PHP parser as a real parser, not using regexes. This is
more complex but allows for better parsing.
Visible changes:
* Scope reporting;
* Variables inside functions are no longer reported (this is a
deliberate choice, but can be easily changed);
* Only the PHP part is parsed (e.g. it doesn't report JavaScript
functions anymore);
* Function arguments spanning several lines are properly reported;
* Interfaces are not yet parsed.
Otherwise the new parser should behave like the old one, at least
where it used to be right. Parsing of more constructs and reporting
more details is planned.
