Use g_set_error() instead of doing it manually and forgetting to check
whether the pointer is NULL or not before dereferencing it.
Spotted by clang --analyze.
The test suite uses a LOG_COMPILER, which requires the parallel-tests
Automake test driver which is the default only since version 1.13, so
explicitly enable it so it is used by earlier versions too.
Moreover, the parallel-tests test diver was introduced by Automake
1.11, as was the option, so we need to depend on it too. It was
released 2009-05-17, which is 2 months after GTK 2.16, the minimum GTK
version we depend on (2009-03-13). If this is a problem, we could
also rework the Automake test layout to use the older and a little
deprecated serial-tests test driver that is the historical one.
Explain operation of tabs and spaces setting.
Explain relation of autoindent settings and indentation type.
Add note regarding filetypes to match braces.
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.
The test results were auto-generated and not manually checked, so they
may be inaccurate. They should be fixed if appropriate if they start
to fail, e.g. when modifying the relevant parser.
CTags' tests that didn't pass weren't imported, but probably should be
added an the relevant parser fixed.
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.
C-style multiline comments, used among others in C, C++ and Java, are
often continued on next lines with an additional space followed by an
asterisk:
1. /* first comment line
2. * continuation line (asterisk is aligned with previous line)
3. * last line */
This fools the indentation with detection because lines 2 and 3 from
the above example have an extra space in what is considered being the
line indentation. In this example, the algorithm would detect an
indentation width of 5 rather than 4, because here most lines have an
indent of 5 -- although they actually have an indent of 4 plus a space
for alignment. This is not a problem in most situations because there
generally are fewer comment continuation lines than actual code lines
which have a indent multiple of the actual indent width, but with some
code with a lot of comments (e.g. short functions with verbose
documentation comments) this might start to fool the algorithm and
give wrong, annoying, results.
So, try to detect these continuation lines and avoid taking them into
account.
