summaryrefslogtreecommitdiffstats
path: root/src/fortrancode.l
Commit message (Collapse)AuthorAgeFilesLines
* Misc. typosluzpaz2017-12-231-1/+1
| | | | | Super trivial typos Some are in qtools/ which I know is a 3rd party dependency but as we know is now obsolete upstream. I reckon it wouldn't be much of an issue to merge neverthless Tacked on several more commits
* Code color of , (comma) together with only in use statementalbert-github2017-11-181-8/+8
| | | | The comma was colored as part of the word only (keywordtype), this should not be the case.
* Bug 733705 - parser misinterpreting fortranalbert-github2017-08-231-66/+79
| | | | Corrected handling of (local) variables as functions as well as handling of non Fortran variables used in Fortran code.
* flex: use %option instead of command line options.Adrian Negreanu2016-09-211-0/+3
|
* Bug 770660 - Code snippet always shows line numbers from 1albert-github2016-09-031-5/+6
| | | | | | | | | 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)
* Merge pull request #501 from ↵Dimitri van Heesch2016-08-201-0/+10
|\ | | | | | | | | albert-github/feature/bug_code_keyword_operator_assignment Color code word OPERATOR and ASSIGNMENT as keyword in FORTRAN code
| * Color code word OPERATOR and ASSIGNMENT as keyword in FORTRAN codealbert-github2016-08-191-0/+10
| |
* | Color code word RESULT as keyword in FORTRAN codealbert-github2016-08-181-1/+6
|/
* Style fixes and added numbering to overloaded membersDimitri van Heesch2016-07-301-1/+1
|
* Changed configuration mechanism to directly access options in order to ↵Dimitri van Heesch2016-01-171-3/+3
| | | | improve performance
* Support flex-2.6.0Dimitri van Heesch2015-11-221-3/+3
|
* Support flex-2.6.0Heiko Becker2015-11-221-1/+1
| | | | | | 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.
* Better handling of implicit statement in source code browseralbert-github2015-08-271-1/+1
| | | | 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.
* drop #include <unistd.h>Adrian Negreanu2015-05-151-2/+2
| | | | Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
* Fortran: fixed format position 73 and further is commentalbert-github2015-01-041-7/+24
| | | | According to the Fortran standard position 73 and further on a line are comment. Until now this was not considered.
* Fortran: code color GOTO as flow keyword.albert-github2015-01-031-1/+1
|
* Supporting linking for methods bound to FORTRAN classes in source definitionsChris Hansen2014-12-211-4/+13
|
* Merge pull request #247 from hansec/FORTRAN_moduleNSDimitri van Heesch2014-12-201-4/+37
|\ | | | | Convert FORTRAN modules to namespaces
| * Remove filtering rule when generating FORTRAN module linksChris Hansen2014-11-301-1/+1
| |
| * Fix rules for closing FORTRAN module and typedef scopesChris Hansen2014-11-281-2/+2
| |
| * Convert FORTRAN modules to namespacesChris Hansen2014-11-211-3/+36
| | | | | | | | This helps fix linking issues and ambiguity related to the difference between classes and modules in FORTRAN 2003+.
* | Merge pull request #263 from albert-github/feature/bug_fortran_call_colorDimitri van Heesch2014-12-141-4/+6
|\ \ | | | | | | Fortran color CALL as keyword
| * | Fortran color CALL as keywordalbert-github2014-12-101-4/+6
| | | | | | | | | | | | Color the word CALL as keyword.
* | | Fortran code color END (regression pull request 259)albert-github2014-12-141-1/+1
|/ / | | | | | | | | | | | | 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.
* | Merge pull request #258 from ↵Dimitri van Heesch2014-12-091-3/+11
|\ \ | | | | | | | | | | | | albert-github/feature/bug_fortran_source_continuation Fortran continuation character seen as begin of function call
| * | Fortran continuation character seen as begin of function callalbert-github2014-12-081-3/+11
| |/ | | | | | | | | 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.
* | Fortran color code of ENDalbert-github2014-12-081-3/+2
|/ | | | 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.
* Merge pull request #237 from albert-github/feature/bug_fortran_codecommentDimitri van Heesch2014-10-211-0/+11
|\ | | | | Last comment of \code{.f90} missing
| * Last comment of \code{.f90} missingalbert-github2014-10-111-0/+11
| | | | | | | | | | | | | | 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.
* | Bug 738063 - Fortran attribute contiguous not identifiedalbert-github2014-10-111-1/+1
|/ | | | Added keywords contiguous and volatile
* Bug 733856 - segfault in QGListIterator while parsing fortran codealbert-github2014-07-301-0/+2
| | | | | 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.
* Fix FORTRAN code function scope testChris Hansen2014-05-271-1/+1
|
* Fix highlighting issuesChris Hansen2014-05-191-6/+25
| | | | | - Fixed highlighting defined type in variable declarations - Corrected parser state following docBlock closure
* Fix unnecessary rules for FORTRAN typesChris Hansen2014-05-121-22/+10
|
* Merge pull request #171 from hansec/fortran_case_regressionDimitri van Heesch2014-05-071-1/+1
|\ | | | | Highlighting corrected for case statements without new line (regression)
| * Fixes regression due to PR 169Chris Hansen2014-05-071-1/+1
| |
* | Coded coloring of flow statements corrected (regression)albert-github2014-05-071-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | 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.
* Merge branch 'select_type' of https://github.com/hansec/doxygen into ↵Dimitri van Heesch2014-05-061-7/+12
|\ | | | | | | | | | | | | hansec-select_type Conflicts: src/fortrancode.l
| * Add type option to FORTRAN select statementsChris Hansen2014-05-051-1/+6
| |
* | Merge pull request #168 from hansec/fortran_keywordsDimitri van Heesch2014-05-061-3/+13
|\ \ | | | | | | Add FORTRAN 2003 keywords and commands
| * | Add FORTRAN 2003 keywords and commandsChris Hansen2014-05-051-3/+13
| |/
* | Merge pull request #167 from hansec/class_vardefDimitri van Heesch2014-05-061-2/+3
|\ \ | | | | | | Add class/procedure vardefs to FORTRAN code highlighting
| * | Added class/procedure vardefs to FORTRAN code highlightingChris Hansen2014-05-051-2/+3
| |/
* | Fixed keyword typeChris Hansen2014-05-051-3/+1
| |
* | Added import keyword to FORTRAN code highlightingChris Hansen2014-05-051-4/+18
|/
* Bug 623299 - Fortran: quotation after define causes erroralbert-github2014-04-211-0/+3
| | | | For the determination whether the file is free or fixed formatted code just see lines starting with # as comment lines
* Some restructuring and some compiler warning fixesDimitri van Heesch2014-03-151-6/+6
|
* Bug 625601 - FORTRAN: recognition free versus fixed formatted codealbert-github2014-03-091-3/+5
| | | | | 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.
* Corrected some definitions for some Fortran keywordsalbert-github2014-02-231-2/+2
|
* Reduced and improved functionality of QListDimitri van Heesch2013-12-301-4/+6
| | | | | | | | | - 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.
generated by cgit v0.12 at 2024-11-10 03:15:57 (GMT)