The GENERATOR_EXIT_IF_NEEDED macro is only used once and it's easier to
read and understand the code if this macro body is written in the code.
Then the comment just before it makes more sense.
Signed-off-by: Damien George <damien@micropython.org>
This check for code_state->ip being NULL was added in
a7c02c4538bb2b986efb1999e00da4d76345767d with a commit message that "When
generator raises exception, it is automatically terminated (by setting its
code_state.ip to 0)". It was also added without any tests to test for this
particular case. (The commit did mention that CPython's test_pep380.py
triggered a bug, but upon re-running this test it did not show any need for
this NULL check of code_state->ip.)
It is true that generators that have completed (either by running to their
end or raising an exception) set "code_state.ip = 0". But there is an
explicit check at the start of mp_obj_gen_resume() to return immediately
for any attempt to resume an already-stopped generator. So the VM can
never execute a generator with NULL ip (and this was true at the time of
the above-referenced commit).
Furthermore, the other parts of the VM just before and after this piece
of code do require (or at least assume) code_state->ip is non-NULL.
Signed-off-by: Damien George <damien@micropython.org>
The optimisation that allows a single check in the VM for either a pending
exception or non-empty scheduler queue doesn't work when threading is
enabled, as one thread can clear the sched_state if it has no pending
exception, meaning the thread with the pending exception will never see it.
This removes that optimisation for threaded builds.
Also fixes a race in non-scheduler builds where get-and-clear of the
pending exception is not protected by the atomic section.
Also removes the bulk of the inlining of pending exceptions and scheduler
handling from the VM. This just costs code size and complexity at no
performance benefit.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This helps with Python-compatibility (see issue #4171) but doesn't
completely resolve it.
Now, `dir()` still computes any properties of the underlying object,
HOWEVER, if the property raises an exception this expression is
captured.
This ability to capture exceptions always existed in
`mp_load_method_protected`, we just need to turn it on via the
`catch_all_exc` boolean parameter.
Add .attr attribute which forwards to self->fun.
A closure is intended to wrap around a function object, so forward any
requested attributes to the wrapped function object.
Signed-off-by: Michael Bentley <mikebentley15@gmail.com>
Prior to this commit, complex("j") would return 0j, and complex("nanj")
would return nan+0j. This commit makes sure "j" is tested for after
parsing the number (nan, inf or a decimal), and also supports the case of
"j" on its own.
Signed-off-by: Damien George <damien@micropython.org>
This separates extmod source files from `py.mk`. Previously, `py.mk`
assumed that every consumer of the py/ directory also wanted to include
extmod/. However, this is not the case. For example, building mpy-cross
uses py/ but doesn't need extmod/.
This commit moves all extmod-specific items from `py.mk` to `extmod.mk` and
explicitly includes `extmod.mk` in ports that use it.
Signed-off-by: David Lechner <david@pybricks.com>
The following changes are made:
- Guard entire file with MICROPY_PY_LWIP, so it can be included in the
build while still being disabled (for consistency with other extmod
modules).
- Add modlwip.c to list of all extmod source in py/py.mk and
extmod/extmod.cmake so all ports can easily use it.
- Move generic modlwip GIT_SUBMODULES build configuration code from
ports/rp2/CMakeLists.txt to extmod/extmod.cmake, so it can be reused by
other ports.
- Remove now unnecessary inclusion of modlwip.c in EXTMOD_SRC_C in esp8266
port, and in SRC_QSTR in mimxrt port.
Signed-off-by: Damien George <damien@micropython.org>
This new logic tracks when an unconditional jump/raise occurs in the
emitted code stream (bytecode or native machine code) and suppresses all
subsequent code, until a label is assigned. This eliminates a lot of
cases of dead code, with relatively simple logic.
This commit combined with the previous one (that removed the existing
dead-code finding logic) has the following code size change:
bare-arm: -16 -0.028%
minimal x86: -60 -0.036%
unix x64: -368 -0.070%
unix nanbox: -80 -0.017%
stm32: -204 -0.052% PYBV10
cc3200: +0 +0.000%
esp8266: -232 -0.033% GENERIC
esp32: -224 -0.015% GENERIC[incl -40(data)]
mimxrt: -192 -0.054% TEENSY40
renesas-ra: -200 -0.032% RA6M2_EK
nrf: +28 +0.015% pca10040
rp2: -256 -0.050% PICO
samd: -12 -0.009% ADAFRUIT_ITSYBITSY_M4_EXPRESS
Signed-off-by: Damien George <damien@micropython.org>
The search in these cases should include all finally handlers that are
after the current ip. If a handler starts at exactly ip then it is
considered "after" the ip. This can happen when END_FINALLY is followed
immediately by a finally handler (from a different finally).
Consider the function:
def f():
try:
return 0
finally:
print(1)
The current bytecode emitter generates the following code:
00 SETUP_FINALLY 5
02 LOAD_CONST_SMALL_INT 0
03 RETURN_VALUE
04 LOAD_CONST_NONE ****
05 LOAD_GLOBAL print
07 LOAD_CONST_SMALL_INT 1
08 CALL_FUNCTION n=1 nkw=0
10 POP_TOP
11 END_FINALLY
12 LOAD_CONST_NONE
13 RETURN_VALUE
The LOAD_CONST_NONE marked with **** is dead code because it follows a
RETURN_VALUE, and nothing jumps to this LOAD_CONST_NONE. If the emitter
could remove this this dead code it would produce:
00 SETUP_FINALLY 4
02 LOAD_CONST_SMALL_INT 0
03 RETURN_VALUE
04 LOAD_GLOBAL print
06 LOAD_CONST_SMALL_INT 1
07 CALL_FUNCTION n=1 nkw=0
09 POP_TOP
10 END_FINALLY
11 LOAD_CONST_NONE
12 RETURN_VALUE
In this case the finally block (which starts at offset 4) immediately
follows the RETURN_VALUE. When RETURN_VALUE executes ip will point to
offset 4 in the bytecode (because the dispatch of the opcode does *ip++)
and so the finally handler will only be found if a >= comparison is used.
It's a similar story for break/continue:
while True:
try:
break
finally:
print(1)
Although technically in this case the > comparison still works because the
extra byte from the UNWIND_JUMP (encoding the number of exception handlers
to unwind) doesn't have a *ip++ (just a *ip) so ip remains pointing within
the UNWIND_JUMP opcode, and not at the start of the following finally
handler. Nevertheless, the change is made to use >= for consistency with
the RETURN_VALUE change.
Signed-off-by: Damien George <damien@micropython.org>
Catch calls to legacy:
MP_REGISTER_MODULE(name, module, enable)
Emit a friendly error suggesting they be rewritten to:
MP_REGISTER_MODULE(name, module).
Signed-off-by: Phil Howard <phil@pimoroni.com>
Make them CIRCUITPY_FULL_BUILD = 0 and rework the boards to have
the same modules enabled (ish.)
Also make ZLIB require FULL_BUILD and disable advanced `micropython`
module APIs by default on all builds.
This adds support for CIRCUITPY_WIFI_SSID and CIRCUITPY_WIFI_PASSWORD
in `/.env`. When both are defined, CircuitPython will attempt to
connect to the network even when user code isn't running. If the
user code attempts to a network with the same SSID, it will return
immediately. Connecting to another SSID will disconnect from the
auto-connected network. If the user code initiates the connection,
then it will be shutdown after user code exits. (Should match <8
behavior.)
This PR also reworks the default displayio terminal. It now supports
a title bar TileGrid in addition to the (newly renamed) scroll area.
The default title bar is the top row of the display and is positioned
to the right of the Blinka logo when it is enabled. The scroll area
is now below the Blinka logo.
The Wi-Fi auto-connect code now uses the title bar to show its
state including the IP address when connected. It does this through
the "standard" OSC control sequence `ESC ] 0 ; <s> ESC \` where <s>
is the title bar string. This is commonly supported by terminals
so it should work over USB and UART as well.
Related to #6174
This file is not executable so shouldn't have the shebang line. This line
can cause issues when building on Windows msvc when the PyPython variable
is set to something other than "python", because it reverts back to using
the shebang line.
The top comment is also changed to """ style which matches all other
preprocessing scripts in the py/ directory.
Signed-off-by: Damien George <damien@micropython.org>
Without this, newer versions of gcc (eg 11.2.0) used with -O2 can warn
about `q_ptr` being maybe uninitialized, because it doesn't know that there
is at least one qstr being written in to this (alloca'd) memory.
As part of this, change the type of `n` to `size_t` so the compiler knows
it's unsigned and can generate better code.
Code size change for this commit:
bare-arm: -28 -0.049%
minimal x86: -4 -0.002%
unix x64: +0 +0.000%
unix nanbox: -16 -0.003%
stm32: -24 -0.006% PYBV10
cc3200: -32 -0.017%
esp8266: +8 +0.001% GENERIC
esp32: -52 -0.003% GENERIC
nrf: -24 -0.013% pca10040
rp2: -32 -0.006% PICO
samd: -28 -0.020% ADAFRUIT_ITSYBITSY_M4_EXPRESS
Signed-off-by: Damien George <damien@micropython.org>
This was made redundant by f2040bfc7ee033e48acef9f289790f3b4e6b74e5, which
also did not update this function for the change to qstr-opcode encoding,
so it does not work correctly anyway.
Signed-off-by: Damien George <damien@micropython.org>
Support for architecture-specific qstr linking was removed in
d4d53e9e114d779523e382c4ea38f0398e880aae, where native code was changed to
access qstr values via qstr_table. The only remaining use for the special
qstr link table in persistentcode.c is to support native module written in
C, linked via mpy_ld.py. But native modules can also use the standard
module-level qstr_table (and obj_table) which was introduced in the .mpy
file reworking in f2040bfc7ee033e48acef9f289790f3b4e6b74e5.
This commit removes the remaining native qstr liking support in
persistentcode.c's load_raw_code function, and adds two new relocation
options for constants.qstr_table and constants.obj_table. mpy_ld.py is
updated to use these relocations options instead of the native qstr link
table.
Signed-off-by: Damien George <damien@micropython.org>
