summaryrefslogtreecommitdiffstatshomepage
path: root/tests/basics/ifcond.py
Commit message (Collapse)AuthorAge
* py/compile: Remove over-eager optimisation of tuples as if condition.Damien George2023-05-03
| | | | | | | | | | | | | | | | | | | | | | | | When a tuple is the condition of an if statement, it's only possible to optimise that tuple away when it is a constant tuple (ie all its elements are constants), because if it's not constant then the elements must be evaluated in case they have side effects (even though the resulting tuple will always be "true"). The code before this change handled the empty tuple OK (because it doesn't need to be evaluated), but it discarded non-empty tuples without evaluating them, which is incorrect behaviour (as show by the updated test). This optimisation is anyway rarely applied because it's not common Python coding practice to write things like `if (): ...` and `if (1, 2): ...`, so removing this optimisation completely won't affect much code, if any. Furthermore, when MICROPY_COMP_CONST_TUPLE is enabled, constant tuples are already optimised by the parser, so expression with constant tuples like `if (): ...` and `if (1, 2): ...` will continue to be optimised properly (and so when this option is enabled the code that's deleted in this commit is actually unreachable when the if condition is a constant tuple). Signed-off-by: Damien George <damien@micropython.org>
* tests: Add tests for things that are not already tested.Damien George2015-03-12
| | | | The aim here is to improve coverage of the code.
* py: Add more compiler optimisations for constant if/while conditions.Damien George2014-10-17
|
* py: Fix 2 bugs in native emitter: jump_or_pop and stack settling.Damien George2014-08-29
Addresses issue #838.