zephyr/scripts/filter-known-issues.py

250 lines
9.0 KiB
Python
Raw Normal View History

#! /usr/bin/env python3
"""
Filters a file, classifying output in errors, warnings and discarding
the rest.
Given a set of regular expressions read from files named *.conf in the
given configuration path(s), of the format:
#
# Comments for multiline regex 1...
#
MULTILINEPYTHONREGEX
MULTILINEPYTHONREGEX
MULTILINEPYTHONREGEX
#
# Comments for multiline regex 2...
#
#WARNING
MULTILINEPYTHONREGEX2
MULTILINEPYTHONREGEX2
Anything matched by MULTILINEPYTHONREGEX will be considered something
to be filtered out and not printed.
Anything matched by MULTILINEPYHONREGEX with a #WARNING tag in the
comment means (optional) means that it describes something that is
considered to be a warning. Print it to stderr.
Anything leftover is considred to be errors, printed to stdout.
"""
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
import argparse
import logging
import mmap
import os
import re
import sre_constants
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
import sys
import traceback
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
exclude_regexs = []
# first is a list of one or more comment lines
# followed by a list of non-comments which describe a multiline regex
config_regex = \
b"(?P<comment>(^\\s*#.*\n)+)" \
b"(?P<regex>(^[^#].*\n)+)"
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
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
def config_import_file(filename):
"""
Imports regular expression from any file *.conf in the given path,
format as given in the main doc
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
"""
try:
with open(filename, "rb") as f:
mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
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
# That regex basically selects any block of
# lines that is not a comment block. The
# finditer() finds all the blocks and selects
# the bits of mmapped-file that comprises
# each--we compile it into a regex and append.
for m in re.finditer(config_regex, mm, re.MULTILINE):
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
origin = "%s:%s-%s" % (filename, m.start(), m.end())
gd = m.groupdict()
comment = gd['comment']
regex = gd['regex']
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
try:
r = re.compile(regex, re.MULTILINE)
except sre_constants.error as e:
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
logging.error("%s: bytes %d-%d: bad regex: %s",
filename, m.start(), m.end(), e)
raise
logging.debug("%s: found regex at bytes %d-%d: %s",
filename, m.start(), m.end(), regex)
if b'#WARNING' in comment:
exclude_regexs.append((r, origin, ('warning',)))
else:
exclude_regexs.append((r, origin, ()))
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
logging.debug("%s: loaded", filename)
except Exception as e:
logging.error("E: %s: can't load config file: %s" % (filename, e))
raise
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
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
def config_import_path(path):
"""
Imports regular expression from any file *.conf in the given path
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
"""
file_regex = re.compile(r".*\.conf$")
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
try:
for dirpath, _, filenames in os.walk(path):
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
for _filename in sorted(filenames):
filename = os.path.join(dirpath, _filename)
if not file_regex.search(_filename):
logging.debug("%s: ignored", filename)
continue
config_import_file(filename)
except Exception as e:
raise Exception(
"E: %s: can't load config files: %s %s" %
(path, e, traceback.format_exc()))
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
def config_import(paths):
"""
Imports regular expression from any file *.conf in the list of paths.
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
If a path is "" or None, the list of paths until then is flushed
and only the new ones are considered.
"""
_paths = []
# Go over the list, flush it if the user gave an empty path ("")
for path in paths:
if path == "" or path is None:
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
logging.debug("flushing current config list: %s", _paths)
_paths = []
else:
_paths.append(path)
logging.debug("config list: %s", _paths)
for path in _paths:
config_import_path(path)
arg_parser = argparse.ArgumentParser(
description=__doc__,
formatter_class=argparse.RawDescriptionHelpFormatter)
arg_parser.add_argument("-v", "--verbosity", action="count", default=0,
help="increase verbosity")
arg_parser.add_argument("-q", "--quiet", action="count", default=0,
help="decrease verbosity")
arg_parser.add_argument("-e", "--errors", action="store", default=None,
help="file where to store errors")
arg_parser.add_argument("-w", "--warnings", action="store", default=None,
help="file where to store warnings")
arg_parser.add_argument("-c", "--config-dir", action="append", nargs="?",
default=[".known-issues/"],
help="configuration directory (multiple can be "
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
"given; if none given, clears the current list) "
"%(default)s")
arg_parser.add_argument("FILENAMEs", nargs="+",
help="files to filter")
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
args = arg_parser.parse_args()
logging.basicConfig(level=40 - 10 * (args.verbosity - args.quiet),
format="%(levelname)s: %(message)s")
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
path = ".known-issues/"
logging.debug("Reading configuration from directory `%s`", path)
config_import(args.config_dir)
exclude_ranges = []
if args.warnings:
warnings = open(args.warnings, "w")
else:
warnings = None
if args.errors:
errors = open(args.errors, "w")
else:
errors = None
def report_error(data):
sys.stdout.write(data.decode('utf-8'))
if errors:
errors.write(data.decode('utf-8'))
def report_warning(data):
sys.stderr.write(data.decode('utf-8'))
if warnings:
warnings.write(data.decode('utf-8'))
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
for filename in args.FILENAMEs:
if os.stat(filename).st_size == 0:
continue # skip empty log files
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
try:
with open(filename, "r+b") as f:
logging.info("%s: filtering", filename)
# Yeah, this should be more protected in case of exception
# and such, but this is a short running program...
mm = mmap.mmap(f.fileno(), 0)
for ex, origin, flags in exclude_regexs:
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
logging.info("%s: searching from %s: %s",
filename, origin, ex.pattern)
for m in re.finditer(ex.pattern, mm, re.MULTILINE):
logging.info("%s: %s-%s: match from from %s %s",
filename, m.start(), m.end(), origin, flags)
if 'warning' in flags:
exclude_ranges.append((m.start(), m.end(), True))
else:
exclude_ranges.append((m.start(), m.end(), False))
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
exclude_ranges = sorted(exclude_ranges, key=lambda r: r[0])
logging.warning(
"%s: ranges excluded: %s",
filename,
exclude_ranges)
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
# Decide what to do with what has been filtered; warnings
# go to stderr and warnings file, errors to stdout, what
# is ignored is just dumped.
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
offset = 0
for b, e, warning in exclude_ranges:
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
mm.seek(offset)
if b > offset:
# We have something not caught by a filter, an error
logging.info("%s: error range (%d, %d), from %d %dB",
filename, offset, b, offset, b - offset)
report_error(mm.read(b - offset))
mm.seek(b)
if warning: # A warning, print it
mm.seek(b)
logging.info("%s: warning range (%d, %d), from %d %dB",
filename, b, e, offset, e - b)
report_warning(mm.read(e - b))
else: # Exclude, ignore it
d = b - offset
logging.info("%s: exclude range (%d, %d), from %d %dB",
filename, b, e, offset, d)
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
offset = e
mm.seek(offset)
if len(mm) != offset:
logging.info("%s: error final range from %d %dB",
filename, offset, len(mm))
report_error(mm.read(len(mm) - offset - 1))
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
del mm
except Exception as e:
logging.error("%s: cannot load: %s", filename, e)
raise
if warnings or errors:
if warnings:
warnings.flush()
if errors:
errors.flush()
if ((os.path.isfile(args.warnings) and os.path.getsize(args.warnings) > 0) or
(os.path.isfile(args.errors) and os.path.getsize(args.errors) > 0)):
print('''\n\n ---- New errors/warnings not tracked as .known-issues/, \
please fix them ----\n''')
if args.warnings:
print(open(args.warnings, "r").read())
if args.errors and (args.errors != args.warnings):
print(open(args.errors, "r").read())
else:
print("\n\nNo new errors/warnings.\n")
print('''\nTo see *all* new error/warnings you must make/ninja clean and \
rebuild from scratch.''')