Fixes:
system/core/base/include/android-base/result.h:
133:94: warning: potentially unintended semicolon [bugprone-suspicious-semicolon]
Bernie says:
it probably means that there's a parser bug with "if constexpr"
maybe, at static analysis pass, the "if constexpr" was evaluated to false,
and the compiler removed the "then" block from the AST...
... and then it thought you had written it that way :-)
https://reviews.llvm.org/D46027
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I25df8eeca4ec06b3180c1cd21b554fc583c5581a
Fixes:
system/core/base/include/android-base/expected.h:
186:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
195:22: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
611:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
To quote Tom Cherry:
I'm a bit confused at what's happening there.
I think it's a bug in the linter itself.
The general solution to that problem is a heavy dose of std::enable_if<>
to hide that constructor when the 'U' parameter is the same class,
but those constructors do have the necessarily std::enable_if<> lines.
I think the problem is that the linter doesn't check that the macro
_ENABLE_IF() expands into std::enable_if<>. Let me try explicitly
putting the std::enable_if<> instead of the macro and check if it
goes away.
I expanded the macro but the linter doesn't still doesn't accept
the format of `std::enable_if_t<(condition_here)>* = nullptr`.
It does accept `typename Enable = std::enable_if_t<(condition_here), void>`,
which is the syntax used on their example here:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-forwarding-reference-overload.html.
That latter syntax doesn't work for us.
See the Notes section on
https://en.cppreference.com/w/cpp/types/enable_if
as a reference for why what we're doing is correct.
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I493ff19208cc104f5f176a36ec23fbcb914388f7
am skip reason: Change-Id I39878b978b47a169c4fe446c43d7347809d15e06 with SHA-1 6025b731e6 is in history
Change-Id: Ie54f5b8f6c5a5a979d9a48002bc4af7ed0261af7
am skip reason: Change-Id Ie67a8bb1bf622319adea15466c42077e0e9b1a18 with SHA-1 4fc9b99329 is in history
Change-Id: I42c60388181f6d8e292dcfe68267f2c0291f93ac
Debugging information for addressing the reason why the process stops as
a zombie, can be found by observing the call trace and running status of
threads in thread group of the zombie process.
Bug: 154667692
Change-Id: Icd7fa2161e88b08fd5ce0d5dc3a3790ed4ac02d1
Added ADB_MDNS_AUTO_CONNECT envionment variable to control which
services to allow auto-connect. By default, only _adb-tls-connect
services can auto-connect, since these services only auto-connect once
paired. _adb services will try to auto-connect to every service found.
Bug: 152636135
Test: ADB_TRACE=1 adb server nodaemon | grep whitelist
Test: ADB_TRACE=1 ADB_MDNS_AUTO_CONNECT=adb adb server nodaemon | grep whitelist
Test: ADB_TRACE=1 ADB_MDNS_AUTO_CONNECT=adb,adb-tls-connect adb server nodaemon | grep whitelist
Test: ADB_TRACE=1 ADB_MDNS_AUTO_CONNECT=adb-tls-connect adb server nodaemon | grep whitelist
Test: ADB_TRACE=1 ADB_MDNS_AUTO_CONNECT=0 adb server nodaemon | grep whitelist
Test: ADB_TRACE=1 ADB_MDNS_AUTO_CONNECT=1 adb server nodaemon | grep whitelist
Change-Id: Ie562ea24fea3d6d96e67b376a0523b09e2778eb7
ABB uses single shared CMD for all operations which improves
reliability.
Bug: b/153486595
Test: atest adb_test adbd_test fastdeploy_test
Change-Id: I1e3da63882c980811ed2e9f5556732b24a041ce5
commit 5327d931ac ("logcatd: fallocate and fadvise to logcat files")
introduced pinning log files in order to avoid f2fs fragmentation.
But, logcatd does not guarantee to write data within fallocated 2MB space.
So, we can see some bytes written beyond 2MB boundary which results in
pinning small chunks across the filesystem. This makes F2FS GC have to unset
the pinning blocks via GC loop. If this happens during checkpoint=disable
at booting time, we can see long delay to mount /data accordingly.
Bug: 136483670
Bug: 137180754
Bug: 149418646
Fixes: 5327d931ac ("logcatd: fallocate and fadvise to logcat files")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I986221d6d1da9b8e46e63d1be98ddf0ce4cb099f
commit 5327d931ac ("logcatd: fallocate and fadvise to logcat files")
introduced pinning log files in order to avoid f2fs fragmentation.
But, logcatd does not guarantee to write data within fallocated 2MB space.
So, we can see some bytes written beyond 2MB boundary which results in
pinning small chunks across the filesystem. This makes F2FS GC have to unset
the pinning blocks via GC loop. If this happens during checkpoint=disable
at booting time, we can see long delay to mount /data accordingly.
Bug: 136483670
Bug: 137180754
Bug: 149418646
Fixes: 5327d931ac ("logcatd: fallocate and fadvise to logcat files")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I986221d6d1da9b8e46e63d1be98ddf0ce4cb099f
