[libc++] Don't make libc++ headers system headers in the modulemap (#205509)
We currently have `[system]` attributes in the modulemap, which
automatically makes the headers inside the module system headers. This
disables warnings when running the tests, which we generally don't want.
We also already have `#pragma GCC system_header` everywhere and use
`-isystem`, so there isn't much need for the tag in the modulemap as
well.
[libc++] Don't #define __unused with glibc in system_reserved_names.gen.py (#206971)
Newer glibc versions use the identifier `__unused`. To run the test
successufly again disable the `__unused` check with glibc.
[LoopInterchange] Add test for direction vector of `[* > =]` (NFC) (#206958)
Add a test case with a direction vector of `[* > =]`. Interchanging the
inner two loops is legal in this case, but it is currently not applied
because the definition of the "normal" form of direction vectors is not
good.
devel/libevent: Update to 2.1.13
Changes in version 2.1.13-stable (01 July 2026)
This release contains several security fixes, affecting users of the
following modules: evbuffer, bufferevent, evtag, evrpc, evdns, evhttp.
If you have a program that uses one of those modules,
or if you distribute libevent, you should upgrade.
Additionally, this release backports some small modernizations to
the libevent codebase, to aid in compiling with the compilers
released over the last few years.
Security Fixes (evtag, evrpc):
Fix an out-of-bounds read in decode_tag_internal.
(Found by @Brubbish. GHSA-fj29-64w6-73h6)
Fix an integer overflow in evtag_unmarshal_header.
(Found by @Brubbish. GHSA-45c6-qx49-89m8)
[39 lines not shown]
devel/libevent: Update to 2.1.13
Changes in version 2.1.13-stable (01 July 2026)
This release contains several security fixes, affecting users of the
following modules: evbuffer, bufferevent, evtag, evrpc, evdns, evhttp.
If you have a program that uses one of those modules,
or if you distribute libevent, you should upgrade.
Additionally, this release backports some small modernizations to
the libevent codebase, to aid in compiling with the compilers
released over the last few years.
Security Fixes (evtag, evrpc):
Fix an out-of-bounds read in decode_tag_internal.
(Found by @Brubbish. GHSA-fj29-64w6-73h6)
Fix an integer overflow in evtag_unmarshal_header.
(Found by @Brubbish. GHSA-45c6-qx49-89m8)
[39 lines not shown]
[MLIR] Prevent CF to SCF transform from erasing blocks still in use (#206310)
While merging blocks, `transformToStructuredCFBranches` may try to erase
blocks that still have uses. This may happen when the block has
self-loop or when it has 1 successor, but the successor has multiple
predecessors. This probably happens only with unreachable blocks in the
function.
Note that running a DCE pass before CF to SCF transform would remove the
triggering assert in the lit test.
Fixes #206086.
/bin/sh fix trap/jobid builtins when run from grandchild
The trap and jobid builtins are designed to allow
T=$(trap)
(etc) to see (output) the traps (or jobs for jobid) of parent shell (the one
running the assignment) to be seen from inside a subshell (here the command
substitution, which it usually would be).
But all that should be reported are the traps (jobs) of the parent of
that subshell, not recursively up the chain.
That is
( T=$(trap) )
should usually be equivalent to T='' as inside a subshell environment
all non-ignored traps are defined to be reset to their defaults
[33 lines not shown]
mk/tools/defaults.mk: Document that TOOL bash must be >= 4.0
macOS ships bash 3 (despite bash4 being released in 2009), and pkgsrc
had a few accomodations for packages that needed bash where bash 3 did
not work. pkgsrc no longer uses macOS system bash as a tool, as such
workarounds being in packages is not reasonable.
Requiring system bash >= 5 to allow use as TOOL would seem reasonable,
as bash 5.0 was released in 2019. However, SmartOS uses bash 4, and
years of bulk builds have turned up no problems from bash 4 as a tool.
Therefore, there is no reason to exclude 4, as the point of setting
minimums is to limit human effort and secondarily reduce needless
machine resource use.
While this commit only adds a comment, it provides a basis to
- remove any workarounds for bash 3 as a tool
- disable TOOLS_PLATFORM.bash settings on platforms where bash is < 4
- add a workaround to a package if it needs TOOL bash but is not ok
with bash 4
[2 lines not shown]
CHERI: make mem{cpy,move}(9) CHERI compatible
- Use intptr_t in place of long as the word type in the core copying
loop where aligned words a copied. This preserved the provenance of
any copied pointers.
- When working with the address of src or dst use ptraddr_t rather than
uintptr_t. This avoid ambigious provenance in expressions involving
multiple addresses.
As a minor tweak, rename the function to memmove since that is the
interface it implements (overlapping src and dst are permitted) and make
memcpy the alias rather than the other way around.
Reviewed by: kib, markj
Effort: CHERI upstreaming
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D57965
CHERI: add sooptcopyinptr to preserve pointer provenance
Most socket options don't involve pointers so make the default
sooptcopyin discard provenance and add a sooptcopyinptr that preserves.
Reviewed by: markj, emaste
Effort: CHERI upstreaming
Sponsored by: DARPA, AFRL, Innovate UK
Differential Revision: https://reviews.freebsd.org/D57665
CHERI: declare mem{cpy,move}_data
Declare kernel-only, provenance-discarding memcpy_data, and memmove_data
APIs intended to copy raw data which does not contain pointers (e.g.,
buffers on their way to or from network or storage devices). On CHERI
architectures, they will explicitly remove tags from capabilities,
removing any provenance. This reduces the risk of accidental spread of
pointers on CHERI systems.
Document that bcopy preserves pointer provenance.
Reviewed by: ziaee, kib, adrian, markj
Effort: CHERI upstreaming
Sponsored by: DARPA, AFRL, Innovate UK
Differential Revision: https://reviews.freebsd.org/D57662
[clang] Fix code completion crash in lambda trailing requires-clause (#206373)
Fixes #201632.
This patch fixes an assertion failure when code completion is triggered
inside an ill-formed lambda's trailing requires-clause, as in
```cpp
void f() {
[]() requires x /*invoke completion here*/
```
https://godbolt.org/z/a66s7Y5cx
When `tok::code_completion` is reached, parsing is cut off before the
end of the declarator. This leaves the lambda's call operator without a
type, thus triggering the `!isNull() && "Cannot retrieve a NULL type
pointer"` assertion when `AddOrdinaryNameResults` calls
`FunctionDecl::getReturnType()` later.
Fix by guarding the `getReturnType()` call with a null check.
[6 lines not shown]
[Dexter] Add support for writing !step values (#203845)
Following from the previous patch, this patch adds support to Dexter for
generating expected values for !step nodes. This is relatively limited:
the kind of !step which this is most well-suited to this is !step
exactly, as the !step order of ignoring extra lines is redundant (all
lines are added as expected values), and !step never can't know what
lines could have been stepped on but weren't without some extra work
(e.g. finding viable breakpoint locations in the enclosing state node).