biology/py-pydeseq2: Update to 0.5.4
Drop support for python 3.10
Modernize build system
A few fixes and enhancements
Changes: https://github.com/scverse/PyDESeq2/releases
Reported by: portscout
[Clang] Fix "Unions cannot be dynamic classes" assertion (#217942)
Fixes #213854
An ill-formed qualified member definition like `void B::foo() {}` inside
a union gets diagnosed, but recovery keeps the declaration around: it
belongs to `B` semantically while sitting lexically inside the union.
Since `B::foo` overrides a virtual function, it counted as a virtual
member of the union when it was added to it, so the union was marked
polymorphic and record layout later asserted with `"Unions cannot be
dynamic classes."`. A non-union enclosing class hits the same bug
silently and just gets a bogus vtable pointer.
The fix is in `HandleDeclarator`: once the qualifier is diagnosed as
naming a different class, the declaration is marked invalid, the same
way we already handle `virtual` in a union. Invalid declarations don't
contribute to the properties of the class they're added to, so the class
can't become polymorphic, while the body is still parsed and the node
stays in the AST. As a side effect, the qualified specializations in
[6 lines not shown]
fork(2), vfork(2): Copy the parent's stack base pointer to the child.
Don't just leak whatever random stack pointer some recycled struct
proc had!
TBD: Move p_stackbase in struct proc so this is covered by the memcpy
above, in a separate commit so we can pull this one up without any
change to the layout of struct proc.
PR kern/60653: posix_spawn(3) causes incorrect stack base information
execve(2): Set p_stackbase in execve_runproc, not execve_loadvm.
execve_loadvm must not have side effects on the running process for
two reasons:
1. If execve(2) fails, it has to be able to back out and return to
the calling process. For example, the shell will execute the
first of a series of candidate paths that works when it searches
$PATH, and if one fails, it has to be able to move on to try the
next.
2. The caller may be the _parent_ process -- this is the case when
we're in posix_spawn.
Instead, it must be set in execve_runproc, after we're committed to
the exec and can't back out -- and we're definitely operating on the
process that is executing a new image, not on its parent!
p_stackbase and its assignment in exec_setup_stack, a subroutine of
[18 lines not shown]
[AMDGPU] Make dead SGPR to not depend on exec in `isIgnorableUse` (#218942)
This creates new sinking opportunities when the SGPR def is dead and as
a result can be safely sunk.
Assisted-by: Claude Code
RISCV: Pass instruction and operand index to isVectorOpUsedAsScalarOp
The helper only used the operand to recover its parent instruction's opcode
and its own operand number. Pass the containing instruction and operand index
so it no longer depends on MachineOperand::getParent().
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
t_signal_and_sp: Link against libpthread unconditionally now.
Required by new test cases added for:
PR kern/60653: posix_spawn(3) causes incorrect stack base information
sys/tests/kern/pdopenpid: pdopenpid(2) is allowed in cap mode
Adjust test to check for ECAPMODE using grandchild instead of child.
Childrens can be opened even in cap mode. Add test for the later.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
pdptrace(2): allow debugging in capability mode
The pdopenpid(2) syscall is allowed in capability mode. Add the chicken
switch security.bsd.ptrace_in_cap_mode, which disables it without
reboot, if needed.
The descriptor passed to pdptrace(2) must have the CAP_PTRACE
capability enabled. This capability is not enabled by default by
pdfork()/pdopenpid(), and the calls do not return a procdesc suitable
for debugging. The opening code must prepare for debugging in advance by
passing the PD_PTRACE_CAP flag to pdfork()/pdopenpid().
For ptrace(2), allow PT_CLEARSTEP and PT_GET_CHILDREN for the current
thread and process in cap mode as well.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
pdopenpid(2): allow in capability mode with restrictions
The pdopenpid() syscall is allowed to open processes which are either
direct children of the caller, or are debuggees already attached to the
calling process. This is reasonable because we could have controlled the
child on fork anyway.
The procdesc-less debuggee can legitimately appear due to ptrace
FOLLOW-FORK mode.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
kern: add p_canopen()
The function defines the policy for allowing to open a pid.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58989
tests/sys/kern/pdwait: adjust test for the addition of CAP_PTRACE
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58586
[flang][CodeGen] Add initial SystemZ ABI support (#208618)
Add initial implementation to enable target-specific code generation and
rewriting support for SystemZ architecture in Flang.
@uweigand @dominik-steenken
---------
Co-authored-by: anoop.kumar6 at ibm.com <anoopk at b35lp63.lnxne.boe>
ptrace: split sys_ptrace()/freebsd32_ptrace()
The code to handle copyin and copyout of the structured parameters is
moved into the helpers.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58586
capsicum: add CAP_PTRACE
The capability will allow the ptrace(2) on the procdesc.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58586
