You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
68 lines
2.3 KiB
68 lines
2.3 KiB
4 years ago
|
-------------------------------------------------------------------------------
|
||
|
|
BUGS:
|
||
|
|
|
||
|
|
Post any bugs to the issue tracker found on the project's GitHub page:
|
||
|
|
https://github.com/uncrustify/uncrustify/issues
|
||
|
|
|
||
|
|
Before you do so, try running with the latest code from git.
|
||
|
|
The bug might have already been fixed.
|
||
|
|
|
||
|
|
If it hasn't already been reported, then you'll need to file a bug report.
|
||
|
|
|
||
|
|
First, reduce your input file to the minimum that still causes the problem.
|
||
|
|
This is important, as a 1000-line input file is much more difficult to diagnose
|
||
|
|
than a 5-line file.
|
||
|
|
|
||
|
|
Next, rename your functions, change your strings, comments, etc, to protect
|
||
|
|
any trade secrets or whatnot.
|
||
|
|
If you attach an input file with a bug, it will most likely appear as a future
|
||
|
|
test case.
|
||
|
|
|
||
|
|
Finally, create a bug report.
|
||
|
|
|
||
|
|
Here's what I like to see in a bug report.
|
||
|
|
|
||
|
|
1. The type of problem (crash, bad formatting, etc)
|
||
|
|
2. The version of uncrustify you tested with (ie, the git hash)
|
||
|
|
3. The operating system
|
||
|
|
4. The input file or code snippet, including the language (C, C++, Java, etc)
|
||
|
|
5. The configuration file you used.
|
||
|
|
If it isn't one of the 'standard' ones, then attach it.
|
||
|
|
6. The expected output (not needed for crash bugs)
|
||
|
|
|
||
|
|
|
||
|
|
If you are the code writing type (and you are, since you are using a code
|
||
|
|
formatting tool), I'd like you to take a quick look and see if you can pinpoint
|
||
|
|
the source of the problem.
|
||
|
|
|
||
|
|
Here is what I do when I get a bug report.
|
||
|
|
|
||
|
|
1. Check for options that control the desired behavior.
|
||
|
|
About half the time a user missed an option.
|
||
|
|
|
||
|
|
2. Run with the supplied input and config to verify the problem.
|
||
|
|
$ uncrustify -c bug.cfg -f bug.c
|
||
|
|
|
||
|
|
2a. For a crash-bug, I create a core dump to quickly find the offending code.
|
||
|
|
$ ulimit -c unlimited
|
||
|
|
$ uncrustify -c bug.cfg -f bug.c
|
||
|
|
$ gdb uncrustify core
|
||
|
|
|
||
|
|
3. Formatting bugs usually land in one of three catagories.
|
||
|
|
a. Incorrectly labeled chunks
|
||
|
|
b. Bad formatting logic or unexpected input
|
||
|
|
c. Missing options
|
||
|
|
|
||
|
|
Debugging help:
|
||
|
|
|
||
|
|
I run with the "-p" option to get a dump of the chunks.
|
||
|
|
$ uncrustify -c bug.cfg -f bug.c -p parsed.txt
|
||
|
|
|
||
|
|
This tells me the configuration and how each chunk is labeled, indented, and
|
||
|
|
otherwise processed.
|
||
|
|
|
||
|
|
I also selectively turn on log levels (the -L command line option) to aid
|
||
|
|
debugging of specific areas of interest.
|
||
|
|
Don't turn on all log levels -- the result is excessive and not at all helpful.
|
||
|
|
|