Escaped newlines were properly handled inside preprocessor directives,
but not otherwise.
Seeing `continue` here suggests the code used to work a long time ago
but some loop refactoring broke it, as now it would not stay in the
loop unless in a preprocessor directive. Or maybe it only ever worked
for preprocessor directives, and the `continue` was superfluous?
Fixes#1370.
This patch is intended a bug reported as sf.bug:364.
https://sourceforge.net/p/ctags/bugs/364/
Writing a test case is helped by Dmitry Gutov.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
Based on 21e74e6a019975045a7975bc611ae63f0917f976 from universal-ctags,
and update the tests accordingly, thanks to @JX7P.
Closes#940.
X-Universal-CTags-Commit-ID: 21e74e6a019975045a7975bc611ae63f0917f976
748137bd1dfa648948d9d127aa3e27b6857db764 improved return types, but as
this test case was added in parallel it wasn't updated as needed for
the new, more correct, results.
This is far from perfect and contains a lot of guessing. It showed
good results based on our tests cases, fixing several issues and not
introducing any more issues (admittedly, after working around a subtle
one regarding D static ifs).
Closes#845.
See http://en.cppreference.com/w/cpp/language/string_literalCloses#877.
---
This contains a pretty ugly hack to fetch the previous character, in
order not to get fooled by string concatenation hidden behind a macro,
like in `FOUR"five"`, which is not a raw string literal but simply the
identifier `FOUR` followed by the string `"five"`.
While this may sound uncommon, it is not and lead to complaints [2][3]
when Scintilla [1] broke this when they introduced C++11 raw string
literal support themselves.
The implementation here still contains a bug with line continuations: a
raw literal of the form:
```c
const char *str = R\
"xxx(...)xxx";
```
is not properly recognized as such, although it's perfectly valid (yet
probably very uncommon). For the record, Scintilla has also suffers
from this but nobody complained about it yet.
[1] http://scintilla.org/
[2] https://sourceforge.net/p/scintilla/bugs/1207/
[3] https://sourceforge.net/p/scintilla/bugs/1454/
See also https://sourceforge.net/p/ctags/bugs/194/
I didn't use the exact upstream patch only altering the C++ code path,
because as far as I know no c.c language recognize two consecutive
colons separated by whitespace as a single token, so there's no point
in carrying on mistakes from the past.
The extension is used by both C and C++ and lexing/parsing C headers with
the C++ parser causes less problems (identifiers named like C++ keywords
get highlighted and tags aren't generated for them) than parsing C++
headers with the C parser (parsing and lexing completely broken).
All of these typos were found by codespell, so credits go the
the authors of this incredibly useful tool.
I manually confirmed and adapted all changes, which includes
reflowing over-long lines or filling up with spaces for alignment.
Some of these typos may need forwarding to their original authors.
codespell reported a lot words where I am unsure; I have not
included those corrections.
Fix handling of scopes starting with a non-ASCII character.
Actually, just drop the check on the first byte of the scope, as it
doesn't seem to serve any purpose as it only checks the first byte (so
isn't any kind of real validation; and as it predates Geany it's
impossible to know the real reason behind this check), and breaks
support for non-ASCII scopes.
`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.
