zephyr/.known-issues
David B. Kinder 621ac8f84b doc: add missing API content
Some API material (from doxygen comments) wasn't included in the
generated documentation because there was no doxygengroup Sphinx
directive to display them. This PR add content into appropriate places
in existing documentation (e.g., Bluetooth Cryptography APIs into the
Bluetooth API doc) and creates two new collections for Display and
Miscellaneous APIs.

Comments added to the .rst files to mention doxygengroups that are
intentionally excluded (because they're organizational groups containing
subgroups that are included).

Sorted the Bluetooth API list, mostly.

Fixed a couple doxygen group titles defined in the include files, and
added a few patterns to filter new "expected" errors from the document
generation process.

Legacy and deprecated APIs remain left out, as intended:

   http_legacy  (net/http_legacy.h)
   spi_interface_legacy  (spi_legacy.h)
   zoap  (net/zoap.h)

fixes: Issue #5051

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2017-12-01 08:58:56 -05:00
..
doc doc: add missing API content 2017-12-01 08:58:56 -05:00
testcases known-issues: update rule for TCF summary line 2016-09-16 11:31:27 -07:00
README
make.conf known-issues: clarify documentation on ignore blocks 2016-09-12 21:55:23 +00:00

README

This directory contains configuration files to ignore errors found in
the build and test process which are known to the developers and for
now can be safely ignored.

To use:

 $ cd zephyr
 $ make SOMETHING >& result
 $ scripts/filter-known-issues.py result

It is included in the source tree so if anyone has to submit anything
that triggers some kind of error that is a false positive, it can
include the "ignore me" file, properly documented.

Each file can contain one or more multiline Python regular expressions
(https://docs.python.org/2/library/re.html#regular-expression-syntax)
that match an error message. Multiple regular expressions are
separated by comment blocks (that start with #). Note that an empty
line still is considered part of the multiline regular expression.

For example

---beginning---
#
# This testcase always fails, pending fix ZEP-1234
#
.*/tests/kernel/grumpy .* FAIL
#
# Documentation issue, masks:
#
# /home/e/inaky/z/kernel.git/doc/api/io_interfaces.rst:28: WARNING: Invalid definition: Expected identifier in nested name. [error at 19]
#  struct dev_config::@65  dev_config::bits
#  -------------------^
#
^(?P<filename>.+/doc/api/io_interfaces.rst):(?P<lineno>[0-9]+): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
^\s+struct dev_config::@[0-9]+  dev_config::bits.*
^\s+-+\^
---end---

Note you want to:

- use relateive paths; instead of
  /home/me/mydir/zephyr/something/somewhere.c you will want
  ^.*/something/somewhere.c (as they will depend on where it is being
  built)

- Replace line numbers with [0-9]+, as they will change

- (?P<filename>[-._/\w]+/something/somewhere.c) saves the match on
  that file path in a "variable" called 'filename' that later you can
  match with (?P=filename) if you want to match multiple lines of the
  same error message.

Can get really twisted and interesting in terms of regexps; they are
powerful, so start small :)