timegm() return type is time_t, not int. Use time_t to prevent the
following compiler warning on Windows:
timemodule.c: warning C4244: '=': conversion from 'time_t' to 'int',
possible loss of data
At the time when an abstract base class' __init_subclass__ runs,
ABCMeta.__new__ has not yet finished running, so in the presence of
__init_subclass__, inspect.isabstract() can no longer depend only on
TPFLAGS_IS_ABSTRACT.
Disable faulthandler to run test_SEH() of test_ctypes to prevent the
following log with a traceback:
Windows fatal exception: access violation
Add support.disable_faulthandler() context manager.
* bpo-30125: Cleanup faulthandler.c
* Use size_t type for iterators
* Add { ... }
* bpo-30125: Fix faulthandler.disable() on Windows
On Windows, faulthandler.disable() now removes the exception handler
installed by faulthandler.enable().
test_io has two unit tests which trigger a deadlock:
* test_daemon_threads_shutdown_stdout_deadlock()
* test_daemon_threads_shutdown_stderr_deadlock()
These tests call Py_FatalError() if the expected bug is triggered
which calls abort(). Use test.support.SuppressCrashReport to prevent
the creation on a core dump, to fix the warning:
Warning -- files was modified by test_io
Before: []
After: ['python.core']
test_quick_connect() runs a thread up to 50 seconds, whereas the
socket is connected in 0.2 second and then the thread is expected to
end in less than 3 second. On Linux, the thread ends quickly because
select() seems to always return quickly. On FreeBSD, sometimes
select() fails with timeout and so the thread runs much longer than
expected.
Fix the thread timeout to fix a race condition in the test.
Detect when the "cc" compiler (and the $CC variable) is the Clang
compiler. The test is needed to add the -fno-strict-aliasing option
on FreeBSD where cc is clang.
Python/dtoa.c is not compiled correctly with clang 4.0 and
optimization level -O2 or higher, because of an aliasing issue on
the double/ULong[2] union.
LLVM bug report:
https://bugs.llvm.org//show_bug.cgi?id=31928
Only define the get_zone() and get_gmtoff() private functions in the
time module if these functions are needed to initialize the module.
The change fixes the following warnings on AIX:
Modules/timemodule.c:1175:1: warning: 'get_gmtoff' defined but not used [-Wunused-function]
Modules/timemodule.c:1164:1: warning: 'get_zone' defined but not used [-Wunused-function]
The @reap_threads decorator and the threading_cleanup() function of
test.support now log a warning if they fail to clenaup threads.
Fix also the usage of support.threading_cleanup() in
test_urllib2_localnet.
The log may help to debug such other warning seen on the AMD64
FreeBSD CURRENT Non-Debug 3.x buildbot:
Warning -- threading._dangling was modified by test_logging
Add setUpModule() and tearDownModule() functions to test_site to
save/restore sys.path at the module level to prevent warning if the
user site directory is created, since site.addsitedir() modifies
sys.path.
Call asyncore.close_all() with ignore_all=True in the tearDown()
method of the test_asyncore base test case. It should prevent keeping
alive sockets in asyncore.socket_map if close() fails with an
unexpected error.
Revert also an unwanted change of my previous commit: remove name
parameter of Thread in test_quick_connect().
Buildbots don't run tests with -vv and so only log "xxx was modified
by test_xxx" which is not enough to debug such random issue. In many
cases, I'm unable to reproduce the warning and so unable to fix it.
Always logging the value before and value after should help to debug
such warning on buildbots.
Don't use addCleanup() in test_quick_connect() because it keeps the
Thread object alive and so @reap_threads fails on its timeout of 1
second. "./python -m test -v test_asyncore -m test_quick_connect"
now takes 185 ms, instead of 11 seconds.
Other minor changes:
* Use "with sock:" to close the socket instead of
try/finally: sock.close()
* Use self.skipTest() in test_quick_connect() to remove one
indentation level and notice user that the test is specific to
AF_INET and AF_INET6
* bpo-29514: Check magic number for micro release
Add a dict importlib.util.EXPECTED_MAGIC_NUMBERS which
details the initial and expected pyc magic number for
each minor release. This gives a mechanism for users to
check if the magic number has changed within a release and
for a test to ensure procedure is followed if a change is
necessary.
Add a test to check the current MAGIC_NUMBER against the
expected number for the release if the current release is
at candidate or final level. On test failure, describe to
the developer the procedure for changing the magic number.
* Simplify magic number release test
Simplify the magic number release test by removing
EXPECTED_MAGIC_NUMBERS table and making the expected
magic number self-contained within the test.
BPO: 29514
* Improve magic number test execution and message
Improve the execution of the magic number test by
using skipUnless for alpha and beta releases, and
directly inheriting from unittest.TestCase rather than
using the machinery for the other tests. Also improve
the error message to explain the reason for caution in
changing the magic number.
BPO: 29514
INADA Naoki
Victor Stinner
Nate
Serhiy Storchaka
Mariatta
csabella
Louie Lu
bladebryan
Charles Renwick
Sebastian Vetter
Benjamin Peterson
Segev Finer
Dong-hee Na
Berker Peksag
cocoatomo
Eric Appelt
Xiang Zhang