[clang] Make -dump-tokens option align tokens (#164894)
When using `-Xclang -dump-tokens`, the lexer dump output is currently
difficult to read because the data are misaligned. The existing
implementation simply separates the token name, spelling, flags, and
location using `'\t'`, which results in inconsistent spacing.
For example, the current output looks like this on provided in this
patch example **(BEFORE THIS PR)**:
<img width="2936" height="632" alt="image"
src="https://github.com/user-attachments/assets/ad893958-6d57-4a76-8838-7fc56e37e6a7"
/>
# Changes
This small PR improves the readability of the token dump by:
+ Adding padding after the token name and after the spelling (the
[9 lines not shown]
[AMDGPU][CodeGen] Implement SimplifyDemandedBitsForTargetNode for readfirstlane. (#190009)
Propagate demanded bits through readfirstlane intrinsic in
AMDGPUISelLowering with SimplifyDemandedBitsForTargetNode
implementation.
This allows upstream zero/sign extensions to be eliminated when only a
subset of bits is used after the intrinsic.
Partially addresses #128390.
[DAG] isKnownToBeAPowerOfTwo - add missing DemandedElts handling to ISD::TRUNCATE and hidden m_Neg pattern (#190190)
Use MaskedVectorIsZero to match X & -X pattern when only DemandedElts
match the negation pattern
Fixes #181654 (properly)
Pull up following revision(s) (requested by yamt in ticket #236):
sys/kern/kern_time.c: revision 1.232
make posix timer family functions reject itimer timer ids
we provide two sets of similar apis:
* BSD itimer api (setitimer, ITIMER_xxx, and friends)
* posix timer api (timer_create and friends)
for some reason, some of posix timer functions
(namely timer_settime, timer_gettime, timer_getoverrun,
timer_delete) are allowed to operate on timer_id=2,
which actually belongs to the BSD itimer. (ITIMER_PROF)
it seems that it has always been this way since they were
introduced on the nathanw_sa branch in 2001.
10 years later, in 2011, it got a bit worse by the addition
of ITIMER_MONOTONIC, which is also accepted by the posix
[5 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #235):
sys/kern/kern_proc.c: revision 1.281
lib/libkvm/kvm_proc.c: revision 1.101
sysctl_doeproc: fix an argument check
this commit fixes a regression in 2015, which made
kvm_getprocs(KERN_PROC_ALL) always fail.
("implementation of KERN_PROC_PATHNAME, some refactoring for KERN_PROC.")
libkvm: fix kvm_getargv/kvm_getenvv
these functions always fail because of a regression in 2022.
("read the ps arguments from the correct place.")
this commit restores them by adding a missing p_psstrp initialization.
Pull up following revision(s) (requested by yamt in ticket #234):
sys/arch/x86/x86/tsc.c: revision 1.64
x86 tsc: decrease the timecounter quality for NVMM
NVMM vcpu loses its TSC "ticks" when switching to a different host cpu.
from the POV of the guest OS (ie. this code), it's observed as random
TSC drifts, which makes it unsuitable for a timecounter source.
bootgrid: maintain scrolling position for both datatree and command actions. Closes https://github.com/opnsense/core/issues/9151
The usage of scrollToRow has been considered, but this contains
too much magic causing all kinds of jumps in scroll position,
causing a user to lose track of the changes they made. The only
downside to this is that when a datatree is expanded at the bottom
of a grid, the associated rows aren't immediately visible until
manually scrolled to.
Pull up following revision(s) (requested by yamt in ticket #233):
sys/kern/sched_4bsd.c: revision 1.48
sched_4bsd.c: honor the upper bound of l_estcpu
otherwise, certain threaded workloads can quickly
accumulate too large l_estcpu.
this change fixes mysterious long (eg 10 seconds) pauses
i've seen occasionally with git. git seems to spawn worker
threads internally these days and happens to hit the condition
of this bug. with very large l_estcpu, the lwp gets effective
priority 0 for a long time. on a busy system, such an lwp
basically will never get a chance to run until the estcpu decay
will eventually make it possible to run again.
it seems this bug has been there since 2007.
("Merge scheduler changes from the vmlocking branch")
[3 lines not shown]
