Branch: refs/heads/master
Author: Colomban Wendling <ban(a)herbesfolles.org>
Committer: Colomban Wendling <ban(a)herbesfolles.org>
Date: Mon, 24 Sep 2012 17:46:48
Commit: 297bca3799a99f68d177e1105d79a69a7d9ef103
https://github.com/geany/geany/commit/297bca3799a99f68d177e1105d79a69a7d9ef…
Log Message:
-----------
JavaScript parser: Don't drop the token after an unbraced if
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.
Modified Paths:
--------------
tagmanager/ctags/js.c
Modified: tagmanager/ctags/js.c
33 files changed, 3 insertions(+), 30 deletions(-)
===================================================================
@@ -805,36 +805,9 @@ static boolean parseIf (tokenInfo *const token)
{
findCmdTerm (token);
- /*
- * The IF could be followed by an ELSE statement.
- * This too could have two formats, a curly braced
- * multiline section, or another single line.
- */
-
- if (isType (token, TOKEN_CLOSE_CURLY))
- {
- /*
- * This statement did not have a line terminator.
- */
- read_next_token = FALSE;
- }
- else
- {
- readToken (token);
-
- if (isType (token, TOKEN_CLOSE_CURLY))
- {
- /*
- * This statement did not have a line terminator.
- */
- read_next_token = FALSE;
- }
- else
- {
- if (isKeyword (token, KEYWORD_else))
- read_next_token = parseIf (token);
- }
- }
+ /* The next token should only be read if this statement had its own
+ * terminator */
+ read_next_token = isType (token, TOKEN_SEMICOLON);
}
return read_next_token;
}
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: TBD).
Branch: refs/heads/master
Author: Colomban Wendling <ban(a)herbesfolles.org>
Committer: Colomban Wendling <ban(a)herbesfolles.org>
Date: Sat, 22 Sep 2012 16:13:07
Commit: be45924f7c04fcc0f511168b9fdb1c8a2d940a5c
https://github.com/geany/geany/commit/be45924f7c04fcc0f511168b9fdb1c8a2d940…
Log Message:
-----------
JavaScript parser: don't set token position information again and again
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.
Modified Paths:
--------------
tagmanager/ctags/js.c
Modified: tagmanager/ctags/js.c
5 files changed, 3 insertions(+), 2 deletions(-)
===================================================================
@@ -370,11 +370,12 @@ static void readToken (tokenInfo *const token)
do
{
c = fileGetc ();
- token->lineNumber = getSourceLineNumber ();
- token->filePosition = getInputFilePosition ();
}
while (c == '\t' || c == ' ' || c == '\n');
+ token->lineNumber = getSourceLineNumber ();
+ token->filePosition = getInputFilePosition ();
+
switch (c)
{
case EOF: longjmp (Exception, (int)ExceptionEOF); break;
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: TBD).
Branch: refs/heads/master
Author: Colomban Wendling <ban(a)herbesfolles.org>
Committer: Colomban Wendling <ban(a)herbesfolles.org>
Date: Sat, 22 Sep 2012 15:52:29
Commit: 772509e898a6847117e28156859483993376118e
https://github.com/geany/geany/commit/772509e898a6847117e281568594839933761…
Log Message:
-----------
ctags: fix improper use of "const" type qualifier
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.
Modified Paths:
--------------
tagmanager/ctags/read.h
Modified: tagmanager/ctags/read.h
9 files changed, 2 insertions(+), 7 deletions(-)
===================================================================
@@ -10,12 +10,6 @@
#ifndef _READ_H
#define _READ_H
-#if defined(FILE_WRITE) || defined(VAXC)
-# define CONST_FILE
-#else
-# define CONST_FILE const
-#endif
-
/*
* INCLUDE FILES
*/
@@ -96,7 +90,8 @@ enum eCharacters {
/*
* GLOBAL VARIABLES
*/
-extern CONST_FILE inputFile File;
+/* should not be modified externally */
+extern inputFile File;
/*
* FUNCTION PROTOTYPES
--------------
This E-Mail was brought to you by github_commit_mail.py (Source: TBD).