| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fortran gives a warning like
```
Error in file .../mic_lib.f90 line: 15, state: 4(SubprogBody)
```
This happens after the upade:
```
Commit: 592aaa4f17d73ec8c475df0f44efaea8cc4d575c [592aaa4]
Date: Sunday, April 11, 2021 9:22:59 PM
Commit Date: Thursday, April 22, 2021 7:34:13 PM
Refactoring: remove implicit conversion from QCString to const char *
```
Looks like an initialization that was previously done automatic doesn't happen anymore.
(Problem found by Fossies in openmpi, gcc, fimex).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes the following in relation to string use
- The implicit convert from 'QCString' to 'const char *' is removed
- Strings parameters use 'const QCString &' as much as possible in favor
over 'const char *'
- 'if (s)' where s is a QCString has been replaced by 'if(!s.isEmpty())'
- data() now always returns a valid C-string and not a 0-pointer.
- when passing a string 's' to printf and related functions 'qPrint(s)' is
used instead of 's.data()'
- for empty string arguments 'QCString()' is used instead of '0'
- The copy() operation has been removed
- Where possible 'qstrcmp(a,b)==0' has been replaces by 'a==b' and
'qstrcmp(a,b)<0' has been replaced by 'a<b'
- Parameters of string type that were default initialized with '= 0' are
no initialized with '= QCString()'
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
|/
|
|
|
| |
- Correct handling of C comment start and end tokens as well as Cpp comment start in rules. These tokes can give "Reached end of file while still inside a (nested) comment..."
- Correct other warnings in respect to lex files
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When having a Fortran file like:
```
!> module docu
MODULE test_mod
INTERFACE
!> @brief iets
SUBROUTINE subr_i(this)
INTEGER this
END SUBROUTINE subr_i
END INTERFACE
!< @brief type brief
TYPE, PUBLIC :: test_type
!> docu
integer i
END TYPE test_type
END MODULE test_mod
```
this is due to the fact that a incorrect start of comment `!<` is used for the `TYPE` and that initiated because the last `SUBROUTINE` argument does not have any documentation.
The actual cause is that at the end of a subroutine the `vtype` is not properly reset.
|
|
|
|
| |
There were 2 routines to recognize whether Fortran code was Fixed of Free format code, though the version in `commentcnv.l` didn't take the settings of `EXTENSION_MAPPING` into account which might lead to incorrect recognition of the format, this has been corrected.
|
| |
|
| |
|
|
|
|
| |
Explicit counting of the removed newlines at the beginning of a documenation block (markdown.cpp) so this number can be added to get a better line number in case of warnings.
|
|\
| |
| | |
Missing links in Fortran in case use statement with upper case characters in name
|
| |
| |
| |
| |
| |
| |
| | |
name
Based on the question: https://stackoverflow.com/questions/62557644/automatic-link-to-fortran-classes-in-method-arguments-description-in-doxygen#62595302
The problem regarding the missing linking was checked and contrary to the idea that it was depending on the `ONLY` clause it was due to the fact that a conversion to lower case was missing.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we have the following small example, we see that the word `subroutine` doesn't start in column 7 but in column 8.
```
subroutine expan()
c2345678 " " lb " " "
end
```
so the code is not converted from fixed form to free form Fortran and in the example (due to the odd number of double quoutes) result in:
```
********************************************************************
Error in file D:/speeltuin/bug_ftn_quote/small.f line: 5, state: 22(String)
********************************************************************
```
The condition regarding the column number was to restrictive.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
free issues
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Spelling corrections as found by codespell and in #561.
Some reported problems were already fixed, others are fixed here, with some exceptions (a,o.):
- "referenceby" in defgen.cpp as this is in the output and I cannot oversee the consequences (looks like none, but ...)
- "HANGEUL_CHARSET" left as is as in some MS documentation is written: 'HANGUL_CHARSET: Also spelled "Hangeul". Specifies the Hangul Korean character set.' (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wmf/0d0b32ac-a836-4bd2-a112-b6000a1b4fc9).
|
| |
|
| |
|
|\
| |
| | |
Fix typos
|
| |
| |
| |
| |
| |
| | |
Found via
```
codespell -q 3 -S *.js,*.po,./src/translator*,*.eps,./doc/changelog.doc -L ang,ans,attribs,ba,behaviour,classe,colour,german,iff,initialise,nam,nd,que,russian,statics,te,tim,uint
```
|
|/ |
|
| |
|
|
|
|
|
| |
Create a consistent way to display the state mnemonics of the different scanners (analogous to the fortranscanner.l)
Use an automatic procedure to generate the routine with the translation of the states to a string.
|
|\
| |
| | |
issue #7200 Fortran warning: type not declared or defined
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
problem in the statement:
```
type(log_handle_type), protected, save, &
bind(c, name="LOG_HANDLE_one") &
:: log_handle_one
```
is the fact that the "bind" attribute is not handled.
- added handling of the bind attribute
- extending the bind definition also with the single quote version.
|
|/
|
|
|
|
|
|
|
|
| |
In Fortran a file that is included is replaced by the doxygen preprocessor by something like:
`# 11 "<path>/<filename>" 2`
when this is in fixed form Fortran and the `<path>/<filename>` is long it is possible that the closing double quote is beyond position 72 and thus not seen resulting in:
```
Error in file <path>/<filename> line: 73, state: 22(String)
```
this is caused as the `#` is not handled properly in prepassFixedForm. The `#` should be handled analogous to e.g. `C`.
|
|\
| |
| |
| | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_endblock_msg
|
| |
| |
| |
| | |
Consistency
|
|/
|
|
| |
Signed-off-by: Adrian Negreanu <groleo@gmail.com>
|
|\
| |
| | |
Windows crash in case of incorrect end statement
|
| |
| |
| |
| | |
Some Fortran compilers accept the END statement instead of the mandatory END TYPE. The code crashes on Windows as no correct END statement is found.
|
|/ |
|