| ------------------------------------------------------------------------------- |
| BUGS: |
| |
| Post any bugs to the issue tracker found on the project's Sourceforge page: |
| http://sourceforge.net/projects/uncrustify |
| |
| 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. |
| |