| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Corrected handling of (local) variables as functions as well as handling of non Fortran variables used in Fortran code.
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch makes the handling of the \snippet and other commands consistent between the different languages (no line numbers anymore with python) and also introduces analogous to \includelineno the command \snippetlineno.
Some non relevant changes:
- *code.l Calculation of the end line was incorrect, in case of a snippet the end line was the number of lines of the snippet and not reltive to the start line.
- *code.l made consistent over the different laguages, enabling exBlock and inlineFragment
- testing/indexpage.xml in test 14 the \snippet command was used with python and giving line numbers, linenumbers are now gone (consistency)
|
|\
| |
| |
| |
| | |
albert-github/feature/bug_code_keyword_operator_assignment
Color code word OPERATOR and ASSIGNMENT as keyword in FORTRAN code
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
improve performance
|
| |
|
|
|
|
|
|
| |
The version checks only considered YY_FLEX_SUBMINOR_VERSION and did not
take YY_FLEX_MINOR_VERSION into account, which made them fail with
flex-2.6.0.
|
|
|
|
| |
When using e.g. IMPLICIT INTEGER only the IMPLICIT was seen as keyword and INTEGER was not seen as keyword. Now types are seen as keywords as well.
|
|
|
|
| |
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
|
|
|
|
| |
According to the Fortran standard position 73 and further on a line are comment. Until now this was not considered.
|
| |
|
| |
|
|\
| |
| | |
Convert FORTRAN modules to namespaces
|
| | |
|
| | |
|
| |
| |
| |
| | |
This helps fix linking issues and ambiguity related to the difference between classes and modules in FORTRAN 2003+.
|
|\ \
| | |
| | | |
Fortran color CALL as keyword
|
| | |
| | |
| | |
| | | |
Color the word CALL as keyword.
|
|/ /
| |
| |
| |
| |
| |
| | |
This is a regression on pull request 259.
Fortran code like:
end if
was not colored properly anymore. This has been corrected with this patch.
|
|\ \
| | |
| | |
| | |
| | | |
albert-github/feature/bug_fortran_source_continuation
Fortran continuation character seen as begin of function call
|
| |/
| |
| |
| |
| | |
In case in fixed format code a line like:
" x ( " existed and the x was on position 6 the "x (" was seen as the start of a function call.
|
|/
|
|
| |
The color for the single END in Fortran code was of the color of the flow type entities though for all the flow entities the entity name is mandatory. For the entity statements of some keywords e.g. SUBROUTINE and FUNCTION the entity name is not mandatory with the END statement. The color of the single END statement has been changed from the flow type to the normal keyword type.
|
|\
| |
| | |
Last comment of \code{.f90} missing
|
| |
| |
| |
| |
| |
| |
| | |
In case e.g. an number of Fortran variables are documented as an example in a \code block and the last line looks like:
INTEGER :: var !< documentation
The "!< documentation" is missing as the last block was not rendered.
Note: STRIP_CODE_COMMENTS has to be NO as otherwise the code comment will anyway, correctly, be absent.
|
|/
|
|
| |
Added keywords contiguous and volatile
|
|
|
|
|
| |
Problem with variables with the name type versus type definitions.
type followed by = is recognized as not being a type definition instead of the use of a variable.
|
| |
|
|
|
|
|
| |
- Fixed highlighting defined type in variable declarations
- Corrected parser state following docBlock closure
|
| |
|
|\
| |
| | |
Highlighting corrected for case statements without new line (regression)
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Which patch 8e8c9a1 (dd. May 6) the rule:
<Start>{FLOW}/[,( \t\n].*
has been changed into"
<Start>{FLOW}/[,( \t\n]
(analogous: <Start>{COMMANDS}/[,( \t\n])
To overcome the warning: fortrancode.l:744: warning, dangerous trailing context.
The result is that the code coloring of (e.g.) the if statements in:
subroutine test_on_if
if (a == b) then
c = d
endif
if(a == b) then
c = d
endif
end subroutine
was removed, due to the fact that the rule: <Start>{ID}{BS}/"(" was used instead of the flow coloring rule.
This patch fixes the rules so the lines are colored again and there is no warning.
|
|\
| |
| |
| |
| |
| |
| | |
hansec-select_type
Conflicts:
src/fortrancode.l
|
| | |
|
|\ \
| | |
| | | |
Add FORTRAN 2003 keywords and commands
|
| |/ |
|
|\ \
| | |
| | | |
Add class/procedure vardefs to FORTRAN code highlighting
|
| |/ |
|
| | |
|
|/ |
|
|
|
|
| |
For the determination whether the file is free or fixed formatted code just see lines starting with # as comment lines
|
| |
|
|
|
|
|
| |
The recognition of the type (free or fixed) of Fortran code is not reliable possible. A well known possibility as used with compilers as well is to specify the type of code by means of the extension.
With EXTENSION_MAPPING it is possible to select the type of Fortran code, when not explicitly set doxygen tries to guess the type of Fortran code.
|
| |
|
|
|
|
|
|
|
|
|
| |
- operations on current index and node (next(), prev(), last(), first()) have been removed.
- access to internal nodes has been removed.
- old QList has been renamed to QInternalList for use inside qtools only.
- added type safe compare, new, and delete operations (compareValues(), newValue(), deleteValue()).
- add compareValues also to QDict for consistency.
- changed doxygen's implementation to comply with the new QList and QDict interface.
|
|
|
|
| |
Added keyword IMPURE analogous to keyword PURE
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case of error messages like:
input buffer overflow, can't enlarge buffer because scanner uses REJECT
it is not always directly clear from which lexical analyzer (.l file) this problem comes.
This patch helps to find these problems and does the following things:
- when using the option -d lex with doxygen each time a lexical analyzer is called at the start a line like the following line will be given:
Entering lexical analyzer: pre.l (for: ..../file.c)
and at the end:
Finished lexical analyzer: pre.l (for: ..../file.c)
- in case the lexical analyzer has been translated with the -d option of lex / flex the above mentioned lines will be given as part of the lexical analyzer output (to stderr) and look like:
--entering lexical analyzer: pre.l (for: ..../file.c)
--finished lexical analyzer: pre.l (for: ..../file.c)
|