| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
We get warnings like:
```
warning: reached end of file while yyextra->inside a 'code' block!
warning: Ignoring \brief command yyextra->inside argument documentation
```
this is due to the fact that the scanner has been made reentrant (inside becomes yyextra->inside and this slipped into the warning strings as well)
|
|\
| |
| |
| | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_unsupported_html
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When having a problem like:
```
/** \file
- Just name <name>
- name plus subname <name subname>
- name plus twice subname <name subname subname>
- name plus subname subname="" <name subname subname="">
*/
```
we get correctly the warnings:
```
.../aa.h:3: warning: Unsupported xml/html tag <name> found
.../aa.h:4: warning: Unsupported xml/html tag <name> found
.../aa.h:5: warning: Unsupported xml/html tag <name> found
.../aa.h:6: warning: Unsupported xml/html tag <name> found
```
but the output doesn't look good as there is `=""` added:
```
Just name <name>
name plus subname <name subname="">
name plus twice subname <name subname="" subname="">
name plus subname subname="" <name subname="" subname="">
```
This patch fixes this output.
|
| | |
|
|\ \
| | |
| | |
| | | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_nospam_email
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When having a simple nospam email address coded like:
```
/** \file
* Big Unknown <big at none dot com>
*/
```
this results in the warning:
```
aa.c:2: warning: Unsupported xml/html tag <big> found
```
and in the HTML output it looks like:
```
Big Unknown <big at none dot com>
```
instead of:
```
Big Unknown <big at none dot com>
```
(Found in a couple of open source projects).
|
|\ \ \
| | | |
| | | | |
Problem with `<hr>` in LaTeX multicolumn cell
|
| | | |
| | | |
| | | |
| | | | |
Small problem with defining `\hrulefilll`, moved code.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In case we have a `<hr>` in a table cell then it is displayed as a horizontal line (in LaTeX) unless it is in a multicolumn cell. In the later case it throws an error:
```
! You can't use `\hrule' here except with leaders.
\DoxyHorRuler ... }{0ex plus 0ex minus 0ex}\hrule
```
We have to use use `\hrulefill` in a table but in combination with the table option of xcolor this gives some problems so a new command has to be defined for this.
See also:
- horizontal rule / line inside a multicolumn field (https://tex.stackexchange.com/questions/506211/horizontal-rule-line-inside-a-multicolumn-field)
- interaction between \usepackage[table]{xcolor} and \hrulefill (https://tex.stackexchange.com/questions/506221/interaction-between-usepackagetablexcolor-and-hrulefill)
|
| | | |
| | | |
| | | |
| | | | |
preceding '|' action
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
https://github.com/albert-github/doxygen into albert-github-feature/issue_7248
|
| | | | |
| | | | |
| | | | |
| | | | | |
Ignore automatically generated anchor names when importing a tag file.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The search for `/*` or /*!` ended at the last `*/` in a file and thus skipping other intermediate block end and new starts. Also the intermediate code was lost see as comment.
The filter pattern used was incorrect and should have been `<"/*" (~["*"])* "*" ("*" | ~["*","/"] (~["*"])* "*")* "/">` (thanks to https://javacc.org/contrib/C.jj).
Here also the space plus one or more `*` at the end beginning of the line are still incorporated as well as multiple `*` before the colosing `*/` this is also filtered.
|
|\ \ \ \ \ |
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
Email address seen as code starter
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Some email addresses give problems in the comment converter as they contain e.g. `@code`, so we try to detect Email addresses (analogous to doctokenizer.l) to prevent these false positives.
The given warning would ne like:
```
aa.h:13: warning: Reached end of file while still inside a (nested) comment. Nesting level 1 (probable line reference: 1)
```
|
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Incorrect NCName in docbook citations
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
In a bibtex reference it is possible to have a colon as the id, but in docbook this will result in:
```
docbook/citelist.xml:5: validity error : xml:id : attribute value _citelist_1CITEREF_pre:post is not an NCName
<varlistentry><term><anchor xml:id="_citelist_1CITEREF_pre:post"/>[1]</term>
```
So the id has to be translated. A colon in an id can only happen in case the names is provided from the outside.
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Fix incorrect reference resolving of enum class values
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
When they share enum value names inside the same namespace.
This is a proposed fix for issue #7427: "Incorrect resolving of
references to enum class values with shared names inside the same
namespace"
|
|/ / / / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | | |
the content
|
|\ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Fixing a number of uninitialized variables based on the coverity output of November 30, 2019
|
| | | | | | | | | | |
|
|\ \ \ \ \ \ \ \ \ \
| |_|/ / / / / / / /
|/| | | | | | | | |
| | | | | | | | | | |
virusxp-memory_leakage_fix
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
namespace
Fixing some memory issues caused by not correctly freed pointers
|
| |_|_|_|/ / / / /
|/| | | | | | | |
| | | | | | | | |
| | | | | | | | | |
free issues
|
| | | | | | | | | |
|
| |_|/ / / / / /
|/| | | | | | | |
|
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
Problem converting UCS big endian file
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
When having a file with a Big Endian BOM this is not always handled in a correct way when using the generic UCS-2 approach, using the explicit version works well.
(problems see with a gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407] and glibc-2.26-lp151.18.7.x86_64).
|
| | | | | | | | | |
|
|/ / / / / / / /
| | | | | | | |
| | | | | | | |
| | | | | | | | |
warning.
|
| | | | | | | | |
|
| | | | | | | | |
|
|/ / / / / / / |
|
| | | | | | | |
|
| | | | | | | |
|
|/ / / / / / |
|
| | | | | | |
|