build: script to filter known issues
This is is a proposal to have a system to filter the output of the
build (compilation, documentation, sanity check and runtime tests)
that eliminates known issues so that whoever sees the output of the
tree can note new issues being added without having to dive on
existing, known ones.
Most common user of this will be the continuous integration system, to
decide what is shown to gerrit as feedback to the user who submitted a
change.
The rationale behind having it in the tree is that if somebody submits
code that introduces a false positive (due to tool limitations) or as
an accepted (normally minor) issue to be fixed later, it can also
submit a "filter" for it without breaking CI.
For example, consider the documentation workaround in include/uart.h
(that will be reverted when this is done):
diff --git a/include/uart.h b/include/uart.h
index a30b211..178bd5e 100644
--- a/include/uart.h
+++ b/include/uart.h
@@ -97,7 +97,7 @@ typedef void (*uart_irq_config_func_t)(struct device *port);
* @param sys_clk_freq System clock frequency in Hz
*/
struct uart_device_config {
- union __unnamed_workaround__ {
+ union {
uint32_t port;
uint8_t *base;
uint32_t regs;
This introduces a harmless warning in the documentation compilation
process due to a limitation in the tools that will be fixed in future
releases. In the meantime, as they accumulate, it makes more difficult
for people to know if *they* introduced any other warnings (or
errors). The configuration in .known-issues/doc/uart.conf matches that
warning and filters it out (and only that), with enough regex glue to work
around subtle context changes (like line numbers).
The implementation is a Python script that can take the build output
and remove what is being told to ignore by a list of configuration
files, each of which contains a list of single/multiline Python
regular expressions.
Addition of said exceptions is caught by CI: it will trigger a
maintainer being included as a reviewer because the as directed by the
entry for the .known-issues in the MAINTAINERS file.
Change-Id: I7939e0726f2c505481592c3a7f5f40fa3e9c62fd
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
2016-06-28 08:57:28 +08:00
#
# Bluetooth unnamed struct definition
#
# FIXME: all these should match the relative filename
#
2019-02-03 00:06:11 +08:00
^(?P<filename>([\-:\\/\w\.])+[/\\]doc[/\\]reference[/\\]bluetooth.rst):(?P<lineno>[0-9]+): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]$
build: script to filter known issues
This is is a proposal to have a system to filter the output of the
build (compilation, documentation, sanity check and runtime tests)
that eliminates known issues so that whoever sees the output of the
tree can note new issues being added without having to dive on
existing, known ones.
Most common user of this will be the continuous integration system, to
decide what is shown to gerrit as feedback to the user who submitted a
change.
The rationale behind having it in the tree is that if somebody submits
code that introduces a false positive (due to tool limitations) or as
an accepted (normally minor) issue to be fixed later, it can also
submit a "filter" for it without breaking CI.
For example, consider the documentation workaround in include/uart.h
(that will be reverted when this is done):
diff --git a/include/uart.h b/include/uart.h
index a30b211..178bd5e 100644
--- a/include/uart.h
+++ b/include/uart.h
@@ -97,7 +97,7 @@ typedef void (*uart_irq_config_func_t)(struct device *port);
* @param sys_clk_freq System clock frequency in Hz
*/
struct uart_device_config {
- union __unnamed_workaround__ {
+ union {
uint32_t port;
uint8_t *base;
uint32_t regs;
This introduces a harmless warning in the documentation compilation
process due to a limitation in the tools that will be fixed in future
releases. In the meantime, as they accumulate, it makes more difficult
for people to know if *they* introduced any other warnings (or
errors). The configuration in .known-issues/doc/uart.conf matches that
warning and filters it out (and only that), with enough regex glue to work
around subtle context changes (like line numbers).
The implementation is a Python script that can take the build output
and remove what is being told to ignore by a list of configuration
files, each of which contains a list of single/multiline Python
regular expressions.
Addition of said exceptions is caught by CI: it will trigger a
maintainer being included as a reviewer because the as directed by the
entry for the .known-issues in the MAINTAINERS file.
Change-Id: I7939e0726f2c505481592c3a7f5f40fa3e9c62fd
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
2016-06-28 08:57:28 +08:00
^[ \t]*$
^[ \t]*\^$
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]$
^[ \t]*$
^[ \t]*\^$
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]$
^.*bt_conn_info.__unnamed__.*$
^[- \t]*\^$
#
2016-07-12 20:14:13 +08:00
# bt_gatt_discover_params unnamed struct definition
#
2019-02-03 00:06:11 +08:00
^(?P<filename>([\-:\\/\w\.])+[/\\]doc[/\\]reference[/\\]bluetooth.rst):(?P<lineno>[0-9]+): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
2016-07-12 20:14:13 +08:00
^[ \t]*
^[ \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
^[ \t]*
^[ \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_gatt_discover_params.__unnamed__.*
^[- \t]*\^
#
build: script to filter known issues
This is is a proposal to have a system to filter the output of the
build (compilation, documentation, sanity check and runtime tests)
that eliminates known issues so that whoever sees the output of the
tree can note new issues being added without having to dive on
existing, known ones.
Most common user of this will be the continuous integration system, to
decide what is shown to gerrit as feedback to the user who submitted a
change.
The rationale behind having it in the tree is that if somebody submits
code that introduces a false positive (due to tool limitations) or as
an accepted (normally minor) issue to be fixed later, it can also
submit a "filter" for it without breaking CI.
For example, consider the documentation workaround in include/uart.h
(that will be reverted when this is done):
diff --git a/include/uart.h b/include/uart.h
index a30b211..178bd5e 100644
--- a/include/uart.h
+++ b/include/uart.h
@@ -97,7 +97,7 @@ typedef void (*uart_irq_config_func_t)(struct device *port);
* @param sys_clk_freq System clock frequency in Hz
*/
struct uart_device_config {
- union __unnamed_workaround__ {
+ union {
uint32_t port;
uint8_t *base;
uint32_t regs;
This introduces a harmless warning in the documentation compilation
process due to a limitation in the tools that will be fixed in future
releases. In the meantime, as they accumulate, it makes more difficult
for people to know if *they* introduced any other warnings (or
errors). The configuration in .known-issues/doc/uart.conf matches that
warning and filters it out (and only that), with enough regex glue to work
around subtle context changes (like line numbers).
The implementation is a Python script that can take the build output
and remove what is being told to ignore by a list of configuration
files, each of which contains a list of single/multiline Python
regular expressions.
Addition of said exceptions is caught by CI: it will trigger a
maintainer being included as a reviewer because the as directed by the
entry for the .known-issues in the MAINTAINERS file.
Change-Id: I7939e0726f2c505481592c3a7f5f40fa3e9c62fd
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
2016-06-28 08:57:28 +08:00
# Bluetooth GATT unnamed struct definition
#
2019-02-03 00:06:11 +08:00
^(?P<filename>([\-:\\/\w\.])+[/\\]doc[/\\]reference[/\\]bluetooth.rst):(?P<lineno>[0-9]+): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
build: script to filter known issues
This is is a proposal to have a system to filter the output of the
build (compilation, documentation, sanity check and runtime tests)
that eliminates known issues so that whoever sees the output of the
tree can note new issues being added without having to dive on
existing, known ones.
Most common user of this will be the continuous integration system, to
decide what is shown to gerrit as feedback to the user who submitted a
change.
The rationale behind having it in the tree is that if somebody submits
code that introduces a false positive (due to tool limitations) or as
an accepted (normally minor) issue to be fixed later, it can also
submit a "filter" for it without breaking CI.
For example, consider the documentation workaround in include/uart.h
(that will be reverted when this is done):
diff --git a/include/uart.h b/include/uart.h
index a30b211..178bd5e 100644
--- a/include/uart.h
+++ b/include/uart.h
@@ -97,7 +97,7 @@ typedef void (*uart_irq_config_func_t)(struct device *port);
* @param sys_clk_freq System clock frequency in Hz
*/
struct uart_device_config {
- union __unnamed_workaround__ {
+ union {
uint32_t port;
uint8_t *base;
uint32_t regs;
This introduces a harmless warning in the documentation compilation
process due to a limitation in the tools that will be fixed in future
releases. In the meantime, as they accumulate, it makes more difficult
for people to know if *they* introduced any other warnings (or
errors). The configuration in .known-issues/doc/uart.conf matches that
warning and filters it out (and only that), with enough regex glue to work
around subtle context changes (like line numbers).
The implementation is a Python script that can take the build output
and remove what is being told to ignore by a list of configuration
files, each of which contains a list of single/multiline Python
regular expressions.
Addition of said exceptions is caught by CI: it will trigger a
maintainer being included as a reviewer because the as directed by the
entry for the .known-issues in the MAINTAINERS file.
Change-Id: I7939e0726f2c505481592c3a7f5f40fa3e9c62fd
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
2016-06-28 08:57:28 +08:00
^[ \t]*
^[ \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
^[ \t]*
^[ \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_gatt_read_params.__unnamed__.*
^[- \t]*\^
2017-11-19 14:55:15 +08:00
#
# Bluetooth mesh unnamed struct definition
#
2019-02-03 00:06:11 +08:00
^(?P<filename>([\-:\\/\w\.])+[/\\]doc[/\\]reference[/\\]bluetooth.rst):(?P<lineno>[0-9]+): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
2017-11-19 14:55:15 +08:00
^[ \t]*
^[ \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected identifier in nested name. \[error at [0-9]+]
^[ \t]*
^[ \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_mesh_model.__unnamed__.*
^[- \t]*\^
2019-12-12 23:09:31 +08:00
#
# Bluetooth mesh pub struct definition
#
^(?P<filename>([\-:\\/\w\.])+[/\\]doc[/\\]reference[/\\]bluetooth[/\\]mesh[/\\]access.rst):(?P<lineno>[0-9]+): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_mesh_model_pub.*
^[- \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_mesh_model_pub.*
^[- \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_mesh_model_pub.*
^[- \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_mesh_model_pub.*
^[- \t]*\^
^(?P=filename):(?P=lineno): WARNING: Invalid definition: Expected end of definition. \[error at [0-9]+]
^.*bt_mesh_model_pub.*
^[- \t]*\^
