| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
ignored
In case of Cpp we also have to consider the case of strings that can contain the `[[...]]` part.
|
|/
|
|
|
|
|
| |
ignored
Only ally the rule `<*>"[["` for Cpp
See also fix d8001efd89146e04d92f5ea41ab27a7de09b6c53 i.e. Problem parsing c++ gnu::visibility (Origin: bugzilla #787952) #6259
|
|
|
|
|
| |
Problem occurs when a line with just a `*` is followed by another line with an `# and some comment. The test on newline has been removed.
Problem is most likely a consequence of Bug #5288 - Asterisks in comment wrongly displayed for @code, i.e. 23f337e64b95d3fa08f32980c866669b190c872f
|
|
|
|
|
|
| |
suspicious text
To escape `\` and `@` not only `\\` and `@@` should be possible but also `\@` and `@\`
|
| |
|
|
|
|
| |
In the fix for issue #677 / bug 743539 only the Java part, in scanner.l, should have been removed and not the other languages in respect to the word "internal", compare also code.l
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |\
| | |
| | |
| | |
| | | |
albert-github/feature/bug_scanner_obsolete_definitions
Remove obsolete definitions from scanner
|
| | |
| | |
| | |
| | | |
Remove some not used definitions from scanner.l (give false positives when searching for some features).
|
| |\ \
| | | |
| | | | |
Bug 677092 - single quote in HTML section of PHP breaks doxygen
|
| | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Close string also when entering a new php (`<?php`) block
Also solves:
Bug 695337 - Inline HTML containing a single apostrophe (') appears to interfere with Doxygen parsing.
Bug 156160 - Doesn't support quotes in HTML code embedded into a PHP script
|
|/ /
| |
| |
| | |
Added a Slice-optimized output mode.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contains the classname
Problem is the '.' in the namespace name.
For Csharp:
namespace N1.n2
{
is equivalent to
namespace N1
{
namespace N2
{
This splitting has to be considered in the scanner so the different namespaces are mentioned. In the code.l the '.' was not handled.
|
|\
| |
| | |
Bug 769414 - PHP: New array syntax not supported when parsing initial value
|
| |
| |
| |
| | |
Implemented possibility string initializations by means of '[' ... ']' construct (besides the already existing 'array(' ... ')'.
|
|/ |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
in java docs
For java the type should not be reset to "@", see also rule <FindFields>","
|
|/
|
|
| |
internal is not a Java reserved word / keyword but was handled as such.
|
|\
| |
| | |
Bug 638606 - Support for C# nullable type
|
| |
| |
| |
| | |
Added, basic, support for C# nullable types.
|
|/
|
|
|
|
| |
symbols in one line with "}
The handling of comment signs inside a string for property definitions has been corrected, by defining parsing rules for these cases so that not the default comment handler will be used (i.e. remove the part behind the comment sign).
|
| |
|
| |
|
|
|
|
|
|
| |
int Property {get; set;} = 23;
The parser was ending the property at the closing bracket,
which resulted in the initializer being assigned to the following property.
|
| |
|
| |
|