-------------------------------------------------------------------------------
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.