[clang-tidy] Support comments in WarningsAsErrors (#171816)
Closes #171792
---------
Co-authored-by: Victor Chernyakin <chernyakin.victor.j at outlook.com>
cmake: fix build with Qt 6.10 (#100)
The 'Qt6FooPrivate' targets have been split into separate CMake files
in Qt 6.9, and require a 'find_package(Qt6FooPrivate)' call starting
with Qt 6.10.
See also: https://bugreports.qt.io/browse/QTBUG-87776
unionfs: detect common deadlock-producing mount misconfigurations
When creating a unionfs mount, it's fairly easy to shoot oneself
in the foot by specifying upper and lower file hierarchies that
resolve back to the same vnodes. This is fairly easy to do if
the sameness is not obvious due to aliasing through nullfs or other
unionfs mounts (as in the associated PR), and will produce either
deadlock or failed locking assertions on any attempt to use the
resulting unionfs mount.
Leverage VOP_GETLOWVNODE() to detect the most common cases of
foot-shooting at mount time and fail the mount with EDEADLK.
This is not meant to be an exhaustive check for all possible
deadlock-producing scenarios, but it is an extremely cheap and
simple approach that, unlike previous proposed fixes, also works
in the presence of nullfs aliases.
PR: 172334
Reported by: ngie, Karlo Miličević <karlo98.m at gmail.com>
[4 lines not shown]
unionfs: Implement VOP_GETLOWVNODE
This function returns the vnode that will be used to resolve the
access type specified in the 'flags' argument, and is useful for
optimal behavior of vn_copy_file_range(). While most filesystems
can simply use the default implementation which returns the passed-
in vnode, unionfs (like nullfs) ideally should resolve the access
request to whichever base layer vnode will be used for the I/O.
For unionfs, write accesses must be resolved through the upper vnode,
while read accesses will be resolved through the upper vnode if
present or the lower vnode otherwise. Provide a simple
unionfs_getlowvnode() implementation that reflects this policy.
Reviewed by: kib, olce
Tested by: pho
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53988
unionfs: Implement VOP_GETLOWVNODE
This function returns the vnode that will be used to resolve the
access type specified in the 'flags' argument, and is useful for
optimal behavior of vn_copy_file_range(). While most filesystems
can simply use the default implementation which returns the passed-
in vnode, unionfs (like nullfs) ideally should resolve the access
request to whichever base layer vnode will be used for the I/O.
For unionfs, write accesses must be resolved through the upper vnode,
while read accesses will be resolved through the upper vnode if
present or the lower vnode otherwise. Provide a simple
unionfs_getlowvnode() implementation that reflects this policy.
Reviewed by: kib, olce
Tested by: pho
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53988
unionfs: detect common deadlock-producing mount misconfigurations
When creating a unionfs mount, it's fairly easy to shoot oneself
in the foot by specifying upper and lower file hierarchies that
resolve back to the same vnodes. This is fairly easy to do if
the sameness is not obvious due to aliasing through nullfs or other
unionfs mounts (as in the associated PR), and will produce either
deadlock or failed locking assertions on any attempt to use the
resulting unionfs mount.
Leverage VOP_GETLOWVNODE() to detect the most common cases of
foot-shooting at mount time and fail the mount with EDEADLK.
This is not meant to be an exhaustive check for all possible
deadlock-producing scenarios, but it is an extremely cheap and
simple approach that, unlike previous proposed fixes, also works
in the presence of nullfs aliases.
PR: 172334
Reported by: ngie, Karlo Miličević <karlo98.m at gmail.com>
[4 lines not shown]
[libc++][filesystem] Applied `[[nodiscard]]` (#171085)
`[[nodiscard]]` should be applied to functions where discarding the
return value is most likely a correctness issue.
- https://libcxx.llvm.org/CodingGuidelines.html
[TableGen] Improve generated comments for RegClassByHwMode tables
Adding a comment for which RegClassByHwMode the entry refers to is
helpful when staring at this generated table.
Pull Request: https://github.com/llvm/llvm-project/pull/171716
