[orc-rt] Remove Session::waitForShutdown. (#191124)
The existing implementation triggered Session shutdown and then blocked
on a std::future that would be unblocked by an on-shutdown callback that
waitForShutdown had installed. Since there is no guarantee that this
callback would be the last one run, the result was that waitForShutdown
only guaranteed that it would not return until the shutdown sequence had
started (rather than completed).
This could have been fixed, but the Session destructor is already
supposed to block until the Session can be safely destroyed, so a
"working" waitForShutdown would be effectively redundant. Since it was
also a potential footgun (calling it from an on-detach or on-shutdown
callback could deadlock) it was safer to just remove it entirely.
Some Session unit tests do rely on testing properties of the Session
after the shutdown sequence has started, so a new utility has been added
to SessionTests.cpp to support this.
shfmt: updated to 3.13.1
3.13.1
- **cmd/shfmt**
- Add support for `[[zsh]]` in EditorConfig files
- Detect the shell variant from filenames like `.zshrc` and `.bash_profile`
- Fix `--apply-ignore` when used with explicit args
- **syntax**
- Revert an accidental change to how array subscripts are formatted
- Never join `;;` with the previous line when formatting
- Fix a bug where `$1[foo]` was parsed as a subscript in Zsh
- Correctly parse `$!` in double quotes in Zsh
- Allow indexing into special parameters in Zsh
- Allow parameter expansions with empty names in Zsh
- **interp**
- Test against Bash 5.3 and fix three new discrepancies
- Fix a few bugs related to `nameref` variables
- Avoid panics when user input encounters unimplemented features
[AMDGPUUsage] Specify what one-as syncscopes do
This matches the currently implemented and (as far as I could determine)
intended semantics of these syncscopes.
The sync scope table is unchanged except for removing its indentation;
otherwise it would be rendered as part of the preceding note.
[LangRef] Specify that syncscopes can affect the monotonic modification order
If a target specifies that atomics with mismatching syncscopes appear
non-atomic to each other, there is no point in requiring them to be ordered in
the monotonic modification order. Notably, the [AMDGPU target user
guide](https://llvm.org/docs/AMDGPUUsage.html#memory-scopes) has specified
syncscopes to relax the modification order for years.
So far, I haven't found an example where this less constrained ordering would
be observable (at least with the AMDGPU inclusive scope rules). Whenever a load
would be able to see two monotonic stores with non-inclusive scope, that's
considered a data race (i.e., the load would return `undef`), so it cannot be
used to observe the order of the stores.
[LangRef][AMDGPU] Specify that syncscope can cause atomic operations to race
Targets should be able to specify that the syncscope of atomic operations
influences whether they participate in data races with each other.
For example, in AMDGPU, we want (and already implement) the load in the
following case to be in a data race (i.e., return `undef` according to the
current definition), because there is an atomic store with workgroup syncscope
executing in a different workgroup:
```
; workgroup 0:
store atomic i32 1, ptr %p syncscope("workgroup") monotonic, align 4
; workgroup 1:
store atomic i32 2, ptr %p syncscope("workgroup") monotonic, align 4
load atomic i32, ptr %p syncscope("workgroup") monotonic, align 4
```
[3 lines not shown]
[IR] Add llvm.masked.{udiv,sdiv,urem,srem} intrinsics (#189705)
Because division by zero is undefined behaviour, when the loop
vectorizer encounters a div that's not unconditionally executed it needs
to replace its divisor with a non-zero value on any lane that wouldn't
have been executed in the scalar loop:
%safedivisor = select <vscale x 2 x i1> %mask, <vscale x 2 x i64> %divisor, <vscale x 2 x i64> splat (i64 1)
%res = udiv <vscale x 2 x i64> %dividend, %safedivisor
https://godbolt.org/z/jczc3ovbr
We need this for architectures like x86 where division by zero (or
overflow for sdiv/srem) can trap. But on AArch64 and RISC-V division
doesn't trap so we don't actually need to mask off any divisors. Not
only that, but there are also dedicated vector division instructions
that can be predicated.
Originally we tried to optimize this on RISC-V by transforming `udiv x,
[11 lines not shown]
[Passes] Enable vectorizers at Oz (#190182)
The way this is handled right now is very inconsistent. When using
`-passes="default<Oz>"` (the code modified here), both vectorizers were
disabled. The clang frontend enables SLP at Oz but not LoopVectorize.
All the LTO backends enable both vectorizers at Oz.
I'm proposing here that `default<Oz>` should enable both vectorizers by
default. There seems to be a consensus that this is the right thing to
do for SLP (as both Clang and LTO backends do this). It's a bit less
clear for LoopVectorize, but given that the implementation already has
special handling for minsize functions (like switching to code size for
cost modelling and disabling various size-increasing transforms) I'm
inclined that we should also be enabling it at minsize.
This is part of trying to make optsize/minsize purely attribute based
and independent of the pipeline optimization level.
python314 py314-html-docs: updated to 3.14.4
Python 3.14.4
Security
gh-145986: xml.parsers.expat: Fixed a crash caused by unbounded C recursion when converting deeply nested XML content models with ElementDeclHandler(). This addresses CVE 2026-4224.
gh-145599: Reject control characters in http.cookies.Morsel update() and js_output(). This addresses CVE 2026-3644.
gh-145506: Fixes CVE 2026-2297 by ensuring that SourcelessFileLoader uses io.open_code() when opening .pyc files.
gh-144370: Disallow usage of control characters in status in wsgiref.handlers to prevent HTTP header injections. Patch by Benedikt Johannes.
gh-143930: Reject leading dashes in URLs passed to webbrowser.open().
Core and Builtins
gh-148157: Fix an unlikely crash when parsing an invalid type comments for function parameters. Found by OSS Fuzz in 492782951.
gh-148144: Initialize _PyInterpreterFrame.visited when copying interpreter frames so incremental GC does not read an uninitialized byte from generator and frame-object copies.
gh-146615: Fix a crash in __get__() for METH_METHOD descriptors when an invalid (non-type) object is passed as the second argument. Patch by Steven Sun.
[188 lines not shown]
python313 py313-html-docs: updated to 3.13.13
Python 3.13.13
macOS
gh-144551: Update macOS installer to use OpenSSL 3.0.19.
gh-137586: Invoke osascript with absolute path in webbrowser and turtledemo.
Windows
gh-144551: Updated bundled version of OpenSSL to 3.0.19.
gh-140131: Fix REPL cursor position on Windows when module completion suggestion line hits console width.
Tests
gh-144418: The Android testbed’s emulator RAM has been increased from 2 GB to 4 GB.
gh-146202: Fix a race condition in regrtest: make sure that the temporary directory is created in the worker process. Previously, temp_cwd() could fail on Windows if the “build” directory was not created. Patch by Victor Stinner.
gh-144739: When Python was compiled with system expat older then 2.7.2 but tests run with newer expat, still skip test.test_pyexpat.MemoryProtectionTest.
[128 lines not shown]
hdf5: add mpi option
While here:
- ignore a file for shell checking because it's a bash script
- comment out unwrap SUBST block because it fails to do anything here
[LangRef] Allow monotonic & seq_cst accesses to inter-operate with other accesses
Currently, the LangRef says that atomic operations (which includes `unordered`
operations, which don't participate in the monotonic modification order) must
read a value from the modification order of monotonic operations.
In the following example, this means that the load does not have a store it
could read from, because all stores it may see do not participate in the
monotonic modification order:
```
; thread 0:
store atomic i32 1, ptr %p unordered, align 4
; thread 1:
store atomic i32 2, ptr %p unordered, align 4
load atomic i32, ptr %p unordered, align 4
```
[18 lines not shown]
[CodeGen] Preserve big-endian trunc in concat_vectors (#190701)
A transform from `concat_vectors(trunc(scalar), undef)` to
`scalar_to_vector(scalar)` is only equivalent for little-endian targets.
On big-endian, that would put the extra upper bytes ahead of the desired
truncated bytes. This problem was seen on Rust s390x in [RHEL-147748].
[RHEL-147748]: https://redhat.atlassian.net/browse/RHEL-147748
Assisted-by: Claude Code
(cherry picked from commit 5df89ae3da8b24804c17479ce74a930783db045e)
