[bazel] Fix bazelisk failures after ORC RTBridge removal and libc float128 (#216505)
…at128
Commit f406aaec5f6dcb8dbe5d7267afdfdf80cea29d32 removed the ORC/RTBridge
directory and relocated its headers directly under
include/llvm/ExecutionEngine/Orc/. This updates OrcJIT and OrcShared in
llvm/BUILD.bazel to remove the obsolete RTBridge header glob patterns.
Additionally, this adds the missing :__support_fputil_float128 target in
libc/BUILD.bazel and includes it in the dependencies of
:__support_math_ceilf128 and :shared_math_headers_for_apfloat.
TAG=agy
CONV=cdc6d2a4-4a43-464a-ae1b-a56f935ee140
archivers/zip: fix command injection vulnerability
Insufficient quoting in the -T option gave rise to the possibility of
a command injection. Apply a fix from the Debian project.
Reported by: nimaje (via IRC)
See also: https://sintonen.fi/advisories/infozip-test-option-command-injection.txt
MFH: 2026Q3
Fully describe the new dotglob option
Move it to the correct place in the list of options (these things
are sorted!) and flesh out the description of what it (now) does a bit.
While here, fix some minor markup issues in an earlier revision relating
to the new -c option to the read built-in.
devel/jj: add a patch to fix the build on big-endian hosts.
This applies the change from this upstream pull request:
https://github.com/facebook/watchman/pull/1238
Admittedly I'm not able to figure out which version of the
serde_bser crate has the fix and why it's not in devel/jj: the
crate appears to be version 0.4.0 both in devel/jj and at the head
of the github development branch, and this fix is in one but
not the other.
Reported upstream at https://github.com/jj-vcs/jj/issues/9992.
sh: fully implement dotglob
Since dotglob has been created, and is now a sh option, implement
it fully, not only for filename completion (but not at all in SMALL
shells).
When dotglob is enabled '*' (etc) matches filenames beginning with
a dot (period, '.') as well as everything else. When it is disabled
the historic practice of only matching files with names starting with
a '.' when the pattern starts (that component) with a '.' continues.
The default (as with most options) is disabled (traditional behaviour).
Note that the names "." and ".." are unaffected by dotglob, they
are only ever matched by a pattern starting with '.'.
Note all of this applies only to filename expansion (aka, glob) and
libedit's filename completion, and not to any other uses of pattern
matching in sh. In all other contexts a '.' is just a character,
wherever it appears, and is matched just the same as anything else.
/bin/sh option list, don't include dotglob in SMALL shells
dotglob is only (currently) used for file completion via libedit.
None of that is included in SMALL shells, so the new dotglob option
is pointless there (just occupies space), just exclude it.
gotosocial: upstream/codeberg version tracking enhancement
Functionnal and cosmetic change. This WIP package should be held back until next gotosocial upstream update.
Add a codeberg tag tracking variable in the Makefile, like many packages pulled from Github for consistency,
easier upstream version changes tracking, and make this package maintenance easier too.
- pkglint
- build using pkgsrc-trunk and bob
- deployed in production
Only match "." and ".." if the filename is non-empty & starts with '.',
regardless of the state of MATCH_HIDDEN_FILES. That's the way bash
actually works, and makes sense.
Also, while here, don't allow calling the completion function to
alter the "match_hidden_files" setting set by EL_MATCH_HIDDEN_FILES
(or not permanently, only for the current match process).
Also, have fn_complete() call fn_complete2() using MATCH_HIDDEN_FILES
if EL_MATCH_HIDDEN_FILES has been set. This gives some purpose to
the global setting, which was otherwise doing nothing at all.
And make the default be to match hidden files (the way libedit used to
work) which seems likely to have been the intent.
[CIR] Mark bit-field access units as their own member kinds
A bit-field access unit is as wide as the compiler decides, which can be
narrower than the declared type of the bit-fields in it, and the member marks
say nothing about that: a unit with a named occupant is `data` and one with only
unnamed occupants is `empty`, the same marks a declared field gets. So a member
holding a 32-bit bit-field of `long long` looks exactly like an `unsigned`
field, and the two are not the same to the ABI. `BitsContainNoUserData`
recurses on the declared type, finds user data past bit 32 in the first and none
in the second, and classic CodeGen coerces the enclosing records to `i64` and
`i32`.
Split the unit cases out as `bitfield` and `empty_bitfield`. A unit holds data
exactly when a named bit-field lands in it, so `isEmptyForABI` answers the same
for every record once it asks `holdsDataForABI` instead of testing for `data`
alone, and padding is untouched. Nothing classifies on the new marks yet, so no
ABI treatment changes. What needs them is pad-aware eightbyte classification,
which cannot tell a record's declared extents from its access units without
them.
[2 lines not shown]
A specially crafted ELF interpreter binary can trigger a KASSERT() in
vmcmd_map_readvn(). While this points at some deficiencies in
elf_load_file(), we have no intention to supporting such weirdly crafted
binaries (even if they're technically valid). So return EINVAL instead.
ok deraadt@
