[clang-format] Keep C++20 module/import decls on a single line (#199459)
This patch fixes #193676.
- Added `UnwrappedLineParser::parseModuleDecl()` to parse C++20 module
declarations.
- Adapted `parseCppModuleImport()` from #193834 and renamed it to
`parseImportDecl()`.
- Used the test cases from the same PR.
- Removed the invalid test cases and fixed an incorrect one in
`FormatTest.cpp`.
---------
Co-authored-by: Björn Schäpers <github at hazardy.de>
[CIR] Initialization of atomic aggregates with padding (#200668)
This patch adds support for the initialization of atomic aggregates with
padding. The changes include:
- During CIRGen, the type `_Atomic(T)` is represented by a CIR struct
`{T, sint8[padding_size]}` if the size of `_Atomic(T)` does not match
the size of `T`. `padding_size` is the difference between the size of
`_Atomic(T)` and `T`.
- CIRGen for the initialization process is updated to handle the
initialization of such CIR struct values.
www/surge: Remove in favor of ftp/surge
Approved by: Jimmy Olgeni <olgeni at FreeBSD.org> (via e-mail)
Reported by: George L. Yermulnik <yz at yz.kiev.ua>
rename(2): do not allow to rename root vnode of the mounted filesystem
Check for tdvp being vp_crossmp. This cannot happen for the normal
rename cases, but could if the target path specified by the syscall
points to the nullfs mount over the regular file. In this case namei()
cannot step over crossmp, and keep it in ni_dvp.
Since crossmp VOP_GETWRITEMOUNT() returns NULL mp, we retry the locking
dance since the belief is that NULL return is transient.
PR: 295826
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57453
renameat(2): when retrying, check for pending signals
The vn_start_write() call there is already interruptible. Check for
user signals before restarting due to ERELOOKUP, or after failed
vn_start_write(). Note that vn_start_write(V_XSLEEP | V_PCATCH)
does not check for signals if not sleeping.
PR: 295826
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57453
[libc++] Assume that <atomic> is available (#199674)
We always define either `_LIBCPP_HAS_C_ATOMIC_IMP` or
`_LIBCPP_HAS_GCC_ATOMIC_IMP`, so we can remove any special handling of
not having an `<atomic>` header.
loader.efi: Fix when staging moves late
Prior to this commit, we'd compute the page tables and have the last
entries point to the staging area. We'd then add some more metadata to
the image and boot. This assumed the staging area didn't need to move
for this last bit of data.
However, if we go over the staging limit, when we copyin new data, we
grow the staging area, usually be moving it to a lower address. This
overage usually happens when we're loading modules and so things work
out nicely. Sometimes we're close to the limit, and we need to do this
growing inside bi_load, after we've computed the page table, making the
page table wrong, and the code we jump to random rather than the btext
routine we normally start at.
To fix this, move computation of the table (but not its allocation) to
after bi_load, but before we call the trampoline.
This problem was most observed when loading microcode for many peole,
[21 lines not shown]
[TableGen] Recompute only the affected UberSet when inheriting reg units (#200962)
CodeGenRegBank::computeRegUnitWeights() runs a fixpoint over all registers;
normalizeWeight() calls the global computeUberWeights() -- which rescans
every UberRegSet, every register, and all of their register units -- each time
a register inherits register units from its subregisters.
Most of the time, we do better by just recomputing one register's
UberSet.
On AMDGPU (21266 registers) with this change, the "Compute reg unit
weights" phase drops from 3.19s to 0.70s (4.5x speedup) and
-gen-register-info improves overall from ~16.4s to ~14.0s.
Revert "[clang-cl] Add new option `/pathmap:<from>=<to>` to replace the path prefix <from> with <to>." (#201981)
Reverts llvm/llvm-project#198664
Causes test failures on
[llvm-clang-aarch64-darwin](https://lab.llvm.org/buildbot/#/builders/190)
bot.
loader.efi: Fix when staging moves late
Prior to this commit, we'd compute the page tables and have the last
entries point to the staging area. We'd then add some more metadata to
the image and boot. This assumed the staging area didn't need to move
for this last bit of data.
However, if we go over the staging limit, when we copyin new data, we
grow the staging area, usually be moving it to a lower address. This
overage usually happens when we're loading modules and so things work
out nicely. Sometimes we're close to the limit, and we need to do this
growing inside bi_load, after we've computed the page table, making the
page table wrong, and the code we jump to random rather than the btext
routine we normally start at.
To fix this, move computation of the table (but not its allocation) to
after bi_load, but before we call the trampoline.
This problem was most observed when loading microcode for many peole,
[19 lines not shown]
