| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for issue #7393
When closing a group on multiple lines, like:
/*! @}
*/
The line count of subsequent lines is wrong (it's one line less than it
should be).
|
| |
|
|\
| |
| |
| | |
https://github.com/albert-github/doxygen into albert-github-feature/issue_7295
|
| |
| |
| |
| | |
documentation has to be added to the "last" entry not to the "first" / "top"
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
|\ \
| | |
| | | |
issue #7358: Ternary conditional and null-coalescing operator in constructor results in faulty warning
|
| | |
| | |
| | |
| | |
| | |
| | | |
results in faulty warning
Problem due to the implementation of "Support for C# nullable types (Origin: bugzilla #638606)" (issue #4064, pull request #645). The used condition was a bit to stringent so later on the function was not recognized as constructor.
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
|\ \ |
|
| |\ \
| | | |
| | | | |
Bug 570798 - \\\< does not work for php constants
|
| | |/
| | |
| | |
| | | |
Handle comment for define analogous to a normal php variable, the closing part is automatically done when the comment is finished (rule: `<DefinePHPEnd>";"`).
|
| |\ \
| | | |
| | | | |
issue 7302: Parsing of template args in single-quotes is incorrect.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
In case we encounter an unescaped single or double quote during specialization we search for the closing quote.
We are cionnsidering potential escape sequences in the strings as well.
|
| |\ \ \
| | |/ /
| |/| | |
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
```
|
|/ / |
|
|/ |
|
|
|
|
| |
to process the string contents
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_endblock_msg
|
| |
| |
| |
| | |
Consistency
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When there is a problem with a backticjk comment block we can get the message:
reached end of file while inside a ````' block!
this is a bit unreadable / non understandable as we see see 4 backticks followed by a single quote, it woulb be more readable when we get
reached end of file while inside a '```' block!
|
|\ \
| | |
| | | |
Bug 437181 - The -d Preprocessor option doesn't work for php, should be in the doc.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
the doc.
- excluded `.php5` files from preprocessing (like other php files)
- made remark about some limits in files that are preprocessed in documentation
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Problem with with comment recognition for group open and closing commands
|
| |/ /
| | |
| | |
| | |
| | | |
Besides the wanted start of comments `//!`, `///`, `/*!` and `/**` also the "normal" comments `//` and `/*` were recognized as starting a comment for the group open (`\{`, `@{`) and group closing (`\}`, `@}`) commands.
This was due to the usage of `?` in the regular expression meaning 0 or 1 times.
|
|/ /
| |
| |
| | |
Signed-off-by: Adrian Negreanu <groleo@gmail.com>
|
| | |
|
|/
|
|
| |
Handle consts separately and in case of CSharp set the static flag.
|
|\
| |
| |
| |
| | |
cfriedt/feature/cfriedt/6955/allow-javadoc-style-comment-blocks-with-a-doxyfile-variable
Allow Javadoc-style comment blocks with a Doxyfile variable
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Javadoc allows comments like this (which I refer to as "banner" comments)
/*****************
*
*****************/
but doxygen does not recognize them.
Instead, the doxygen manual says to do this
/*************//**
*
****************/
which some users aren't even aware is required. It also behaves poorly with clang-format.
I'm proposing to add a Doxyfile boolean option JAVADOC_BANNER which will default to NO. When set to YES, it will consider the first and second comments above to be equivalent.
However, I don't believe that the JAVADOC_BANNER option should default to YES, as there are likely a number of projects who have used the former syntax with full expectation that it would *not* appear in their documentation.
At least having the JAVADOC_BANNER default to NO allows users to opt-in voluntarily by adding JAVADOC_BANNER = YES to their Doxyfile. If the consensus is to make it a default at a later time, first a warning can be added during build that should trigger users to modify their comment style, and then eventually the default could be set to JAVADOC_BANNER = YES, or the config option could be removed entirely and it would just always be enabled.
|
|/
|
|
| |
Added scope save and restore before and after namespace parsing
|
| |
|
|
|
|
|
|
| |
In case of an email address like abc@code-factory.org we get the message like:
warning: reached end of file while inside a code block!
due to the fact that the email address contains a '-'.
|
|
|
|
| |
The `...` argument was not documented in case of inline parameter documentation, with `\param` it was possible to document the `...` argument.
|
|\
| |
| |
| | |
https://github.com/albert-github/doxygen into albert-github-feature/bug_136299
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Besides the `p` tag there were a number of other tags were also the attributes were lost:
- `br`
- `hr`
- `a` in case of used as an anchor i.e. with the `name=` attribute
In case of a `caption` with a `table` and no `id=` attribute with the `caption` there was still an anchor generated
In scanner.l the warnings message was a bit unclear.
|