Fixes this pylint warning:
Comparison to True should be just 'expr' (singleton-comparison)
Getting rid of pylint warnings for a CI check.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fixes pylint warnings like this one:
doc/conf.py:325:0: W1401: Anomalous backslash in string: '\s'.
String constant might be missing an r prefix.
(anomalous-backslash-in-string)
The reason for this warning is that backslash escapes are interpreted in
non-raw (non-r-prefixed) strings. For example, '\a' and r'\a' are not
the same string (first one has a single ASCII bell character, second one
has two characters).
It just happens that there's no \s (or \., or \/) escape for example,
and '\s' turns into two characters (as needed for a regex). It's risky
to rely on stuff like that regexes though. Best to make them raw strings
unless they're super trivial.
Also note that '\s' and '\\s' turn into the same string.
Another tip: A literal ' can be put into a string with "blah'blah"
instead of 'blah\'blah'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Discovered with pylint3.
Use the placeholder name '_' for unproblematic unused variables. It's
what I'm used to, and pylint knows not to flag it.
Python tip:
for i in range(n):
some_list.append(0)
can be replaced with
some_list += n*[0]
Similarly, 3*'\t' gives '\t\t\t'.
(Relevant here because pylint flagged the loop index as unused.)
To do integer division in Python 3, use // instead of /.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
When building incrementally, filter-known-issues.py reports a varying
and totally different set of "new" issues than when building from
scratch. Warnings for unrelated upstream code disappearing and
re-appearing are especially confusing. Expand the messages a bit to
clarify.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
In order to get rid of doc/scripts/filter-doc-log.sh to make building
the documentation cross-platform, include the functionality in there in
the already existing filter-known-issues.py.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
filter-known-issues (used to remove "expected" messages from log files
during doc and test builds) now properly handles an empty log file
(there won't be anything to filter).
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This patch fixes following error of python script.
TypeError: cannot use a string pattern on a bytes-like object
Jira: ZEP-2290
Signed-off-by: Punit Vara <punit.vara@intel.com>
This patch ports helper scripts from python2 to python3
with following changes:
- print should be used with () in python3
- resolved bytes-like object is required, not 'str'
- added python3 header
ZEP-2054
Signed-off-by: punit vara <punit.vara@intel.com>
This is a corner case that barely hits and thus we had not seen it
before.
Change-Id: Ie1420a4c866834e5a233985c6b8a19643426a1f5
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Introduce support to tag some issues as warnings, that can be printed
but not considered errors.
Added the ability to write the errors and warnings to split files, for
later reporting.
Added a more consistent help.
Change-Id: Ia75430c3337385afca59595437168ab643c92911
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
At least one Linux distribution (Arch) has made python 3 the default
interpreter, and Debian and Ubuntu have expressed a desire to eventually
make this the case. As such, invoking 'python' or '/usr/bin/python'
will possibly run python 3 instead of version 2.
Distributions have included a 'python2' link for quite some time now,
and given that we have some scripts that require python 3, we should be
explicit about those that require python 2.
In addition, be more consistent about how python is invoked, preferring
the:
#!/usr/bin/env python2
construct rather than a hardcoded path to python. This allows the user
to have an alternative python in their path that will be used in
preference to the system provided version.
Jira: ZEP-1548
Change-Id: I125c2af808dc268f74277bc97a092df3acad23c0
Signed-off-by: David Brown <david.brown@linaro.org>
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>
Ulf Magnusson