2017-06-08 17:10:48 +08:00
|
|
|
#! /usr/bin/env python3
|
2017-01-21 07:06:59 +08:00
|
|
|
"""
|
|
|
|
Filters a file, classifying output in errors, warnings and discarding
|
|
|
|
the rest.
|
|
|
|
|
2019-06-19 02:45:40 +08:00
|
|
|
Given a set of regular expressions read from files named *.conf in the
|
2017-01-21 07:06:59 +08:00
|
|
|
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
|
2017-01-21 07:06:59 +08:00
|
|
|
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
|
2017-01-21 07:06:59 +08:00
|
|
|
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 = []
|
|
|
|
|
2017-01-21 07:06:59 +08:00
|
|
|
# first is a list of one or more comment lines
|
|
|
|
# followed by a list of non-comments which describe a multiline regex
|
|
|
|
config_regex = \
|
2019-03-22 04:38:03 +08:00
|
|
|
b"(?P<comment>(^\\s*#.*\n)+)" \
|
2017-06-30 13:10:57 +08:00
|
|
|
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
|
|
|
|
2017-12-12 21:19:25 +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):
|
|
|
|
"""
|
2019-06-19 02:45:40 +08:00
|
|
|
Imports regular expression from any file *.conf in the given path,
|
2017-01-21 07:06:59 +08:00
|
|
|
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:
|
2017-12-12 21:19:25 +08:00
|
|
|
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.
|
2017-01-21 07:06:59 +08:00
|
|
|
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())
|
2017-01-21 07:06:59 +08:00
|
|
|
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:
|
2017-01-21 07:06:59 +08:00
|
|
|
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",
|
2017-01-21 07:06:59 +08:00
|
|
|
filename, m.start(), m.end(), regex)
|
2017-06-30 13:10:57 +08:00
|
|
|
if b'#WARNING' in comment:
|
2017-01-21 07:06:59 +08:00
|
|
|
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:
|
2017-01-21 07:06:59 +08:00
|
|
|
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
|
|
|
|
2017-12-12 21:19:25 +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):
|
|
|
|
"""
|
2019-06-19 02:45:40 +08:00
|
|
|
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
|
|
|
"""
|
2019-03-22 04:38:03 +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:
|
2019-03-20 02:28:24 +08:00
|
|
|
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:
|
2017-12-12 21:19:25 +08:00
|
|
|
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):
|
|
|
|
"""
|
2019-06-19 02:45:40 +08:00
|
|
|
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:
|
2017-12-12 21:19:25 +08:00
|
|
|
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)
|
|
|
|
|
2017-12-12 21:19:25 +08:00
|
|
|
|
2017-01-21 07:06:59 +08:00
|
|
|
arg_parser = argparse.ArgumentParser(
|
2017-12-12 21:19:25 +08:00
|
|
|
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")
|
2017-12-12 21:19:25 +08:00
|
|
|
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()
|
|
|
|
|
2017-12-12 21:19:25 +08:00
|
|
|
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 = []
|
|
|
|
|
2017-01-21 07:06:59 +08:00
|
|
|
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):
|
2017-06-08 17:10:48 +08:00
|
|
|
sys.stdout.write(data.decode('utf-8'))
|
2017-01-21 07:06:59 +08:00
|
|
|
if errors:
|
2018-07-11 23:06:08 +08:00
|
|
|
errors.write(data.decode('utf-8'))
|
2017-01-21 07:06:59 +08:00
|
|
|
|
2017-12-12 21:19:25 +08:00
|
|
|
|
2017-01-21 07:06:59 +08:00
|
|
|
def report_warning(data):
|
2018-07-11 23:06:08 +08:00
|
|
|
sys.stderr.write(data.decode('utf-8'))
|
2017-01-21 07:06:59 +08:00
|
|
|
if warnings:
|
2018-07-11 23:06:08 +08:00
|
|
|
warnings.write(data.decode('utf-8'))
|
2017-12-12 21:19:25 +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
|
|
|
for filename in args.FILENAMEs:
|
2017-09-22 00:47:31 +08:00
|
|
|
if os.stat(filename).st_size == 0:
|
2017-12-12 21:19:25 +08:00
|
|
|
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)
|
2017-01-21 07:06:59 +08:00
|
|
|
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):
|
2017-01-21 07:06:59 +08:00
|
|
|
logging.info("%s: %s-%s: match from from %s %s",
|
2017-12-12 21:19:25 +08:00
|
|
|
filename, m.start(), m.end(), origin, flags)
|
2017-01-21 07:06:59 +08:00
|
|
|
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])
|
2017-12-12 21:19:25 +08:00
|
|
|
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
|
|
|
|
2017-01-21 07:06:59 +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
|
2017-01-21 07:06:59 +08:00
|
|
|
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:
|
2017-01-21 07:06:59 +08:00
|
|
|
# We have something not caught by a filter, an error
|
|
|
|
logging.info("%s: error range (%d, %d), from %d %dB",
|
2017-12-12 21:19:25 +08:00
|
|
|
filename, offset, b, offset, b - offset)
|
2017-01-21 07:06:59 +08:00
|
|
|
report_error(mm.read(b - offset))
|
|
|
|
mm.seek(b)
|
2019-09-03 18:25:20 +08:00
|
|
|
if warning: # A warning, print it
|
2017-01-21 07:06:59 +08:00
|
|
|
mm.seek(b)
|
|
|
|
logging.info("%s: warning range (%d, %d), from %d %dB",
|
2017-12-12 21:19:25 +08:00
|
|
|
filename, b, e, offset, e - b)
|
2017-01-21 07:06:59 +08:00
|
|
|
report_warning(mm.read(e - b))
|
|
|
|
else: # Exclude, ignore it
|
|
|
|
d = b - offset
|
|
|
|
logging.info("%s: exclude range (%d, %d), from %d %dB",
|
2017-12-12 21:19:25 +08:00
|
|
|
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:
|
2017-02-25 08:42:27 +08:00
|
|
|
logging.info("%s: error final range from %d %dB",
|
|
|
|
filename, offset, len(mm))
|
2017-01-21 07:06:59 +08:00
|
|
|
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)
|
2017-01-21 07:06:59 +08:00
|
|
|
raise
|
2018-07-11 23:06:08 +08:00
|
|
|
|
|
|
|
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)):
|
2019-02-27 02:37:59 +08:00
|
|
|
print('''\n\n ---- New errors/warnings not tracked as .known-issues/, \
|
|
|
|
please fix them ----\n''')
|
2018-07-11 23:06:08 +08:00
|
|
|
if args.warnings:
|
|
|
|
print(open(args.warnings, "r").read())
|
|
|
|
if args.errors and (args.errors != args.warnings):
|
|
|
|
print(open(args.errors, "r").read())
|
|
|
|
else:
|
2018-07-12 23:37:18 +08:00
|
|
|
print("\n\nNo new errors/warnings.\n")
|
2018-07-11 23:06:08 +08:00
|
|
|
|
2019-02-27 02:37:59 +08:00
|
|
|
print('''\nTo see *all* new error/warnings you must make/ninja clean and \
|
|
|
|
rebuild from scratch.''')
|