This is related to #12802 which makes a similar change, but I think it's worth putting this in a dedicated PR for visibility.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:   -16 -0.009% 
   unix x64:  -120 -0.014% standard
      stm32:   -48 -0.012% PYBV10[incl -8(bss)]
     mimxrt:   -40 -0.011% TEENSY40
        rp2:   -44 -0.005% RPI_PICO_W[incl -4(bss)]
       samd:   -52 -0.020% ADAFRUIT_ITSYBITSY_M4_EXPRESS[incl -4(bss)]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.42%. Comparing base (1548132) to head (1d95f35).

@@           Coverage Diff           @@
##           master   #15486   +/-   ##
=======================================
  Coverage   98.42%   98.42%           
=======================================
  Files         161      161           
  Lines       21252    21252           
=======================================
  Hits        20918    20918           
  Misses        334      334           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Ah, for some reason I had in my head that pyexec_system_exit was only being used on unix port, not for the bare metal ones.
I see now in this isolated PR how it's used in the embedded ports to control the soft reset.

Regardless, this looks good to me and I think it makes sense for SystemExit to soft-reboot by default.

It's certainly true that there could be other users out there expecting to use it as a silent drop to repl, but that seems fairly unlikley to me?
Either way, said users could still catch it and drop to repl themselves in their main.py as a fairly simple workaround.

It's certainly true that there could be other users out there expecting to use it as a silent drop to repl, but that seems fairly unlikley to me?

Yes, it's possible some code is relying on this behaviour. But it would be an uncommon use, I'm guessing.

Either way, said users could still catch it and drop to repl themselves in their main.py as a fairly simple workaround.

Exactly. And doing it that way (with an except SystemExit) would be more explicit in the code, what the intended behaviour is.

I like this change! since an embedded system is supposed to run indefinitely after being deployed, so doing a soft reset after a SystemExit seems more consistent and logical.

+1 to this. It makes sense and prevents surprises related to DMA, PIO, etc allocation on rp2 at least. I don't believe we have any deployments or devices using SystemExit to mean "exit to repl" at the moment, but if we do it's just another thing for us to fix.

Thanks for the reviews!

Nice one, I'll rebase my PR onto master

Unfortunately this change is not fully compatible with CPython behaviour.

Running CPython with -i for inspect mode, and running a script that doe raise SystemExit (or sys.exit()), the script finishes and then it drops to the REPL. You need to issue a second raise SystemExit to actually exit from the REPL back to the shell:

$ cat test.py
print(123)
raise SystemExit
$ python -i test.py
123
Traceback (most recent call last):
  File "test.py", line 2, in <module>
    raise SystemExit
SystemExit
>>>
>>> raise SystemExit
$

But with this PR (which is merged), on bare-metal a raise SystemExit in a running program, eg main.py, will exit the program and skip the REPL and go straight to a soft reset (similar CPython exiting).

If we consider the REPL on bare-metal to be the equivalent of -i inspect mode in CPython, then raise SystemExit should drop to the REPL, which is what it used to do, but now it doesn't 😞

I see two options:

1. Leave things as they currently are, raise SystemExit does a soft reset (ie doesn't drop to the REPL). The justification is that bare-metal ports are already different enough to CPython on a desktop (eg no sys.args, raw vs friendly REPL, etc) that this additional difference doesn't matter.
2. Revert the change here so raise SystemExit drops to the REPL. And then machine.soft_reset() is used to skip the REPL and go straight to a soft reset.

Note that option (1) means there's no clean way for an application to abort and drop to the REPL. You would need to create a custom exception derived from BaseException and raise that (eg raise SystemAbort). I guess that's acceptable.

If we consider the REPL on bare-metal to be the equivalent of -i inspect mode in CPython, then raise SystemExit should drop to the REPL, which is what it used to do, but now it doesn't 😞

@dpgeorge I don't quite follow: if this is optional behaviour on CPython (enabled by -i) then why would we consider MicroPython's default behaviour to be the equivalent of that rather than the equivalent of CPython's default behaviour?

I don't quite follow: if this is optional behaviour on CPython (enabled by -i) then why would we consider MicroPython's default behaviour to be the equivalent of that rather than the equivalent of CPython's default behaviour?

That's a good point, and maybe that is the right way to look at it.

My thinking was that bare-metal has inspect mode that is switched on by default. Considering you can't specify command-line options on bare-metal, this seems reasonable? Bare-metal is kind of like CPython's python -i boot.py main.py (except you can't run two scripts in succession like that in the same namespace).

Bare-metal is kind of like CPython's python -i boot.py main.py (except you can't run two scripts in succession like that in the same namespace).

Oh, I see the reasoning now. I guess, as you say, MicroPython on bare metal doesn't cleanly map to either "inspect mode" or regular CPython behaviour at the moment - but I can see the resemblance to inspect mode.

Note that option (1) means there's no clean way for an application to abort and drop to the REPL. You would need to create a custom exception derived from BaseException and raise that (eg raise SystemAbort). I guess that's acceptable.

It's hacky but another option would be to programmatically raise KeyboardInterrupt, yes?

For my 2c, having an automatically executed embedded application automatically drop to a REPL on "exit" seems more like a footgun than useful behaviour in most circumstances, but it's possible I'm not thinking through all the ways people might want to use this.

It's hacky but another option would be to programmatically raise KeyboardInterrupt, yes?

Yes. Or just raise BaseException (which usually nothing ever catches).

For my 2c, having an automatically executed embedded application automatically drop to a REPL on "exit" seems more like a footgun than useful behaviour in most circumstances

Yes, I tend to agree with that. You could then argue that we shouldn't ever drop to the REPL (eg on an uncaught exception), but then things like mpremote would never work. So we need to make some compromise somewhere.