This will suppress warning like:
system/chre/chpp/app.c:637:3: warning: Call to function 'memset' is insecure
as it does not provide security checks introduced in the C11 standard.
Replace with analogous functions that support length arguments or provides
boundary checks such as 'memset_s' in case of C11
[clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
Test: WITH_TIDY=1 CLANG_ANALYZER_CHECKS=1 make tidy-system-chre-chpp_subset
Change-Id: I87a7bba31aa10260fc408317a8cd54bf80c03152
This flag has never done anything for ld.lld, since it has this behavior
by default (and actually can't turn it off either). It's now being
removed as a valid flag from ld.lld, so it's time for Android to drop
the unnecessary flags. See https://reviews.llvm.org/D118942.
Test: builds
Change-Id: I22c344b7a55e275c1fbd5fef25f85e97a39de5c4
noOverrideExternalGlobalCflags is a new set of flags intended to be
added at the end of the command line for 3rd party projects like
external/, hardware/, vendor/, and more. Our previous flags for external
projects occur way too early on the command line, leading to issues with
use for suppressing diagnostics. Note that support for this variable in
build/make is currently unimplemented, as there are no projects that
would depend on it. It could be added in the future, if it turns out to
be useful.
This change initially applies `-Wno-unused-but-set-variable` and
`-Wno-unused-but-set-parameter` to external projects because these
upstream projects aren't easily fixed, and the risk of actual bugs is
low.
Bug: http://b/197240255
Test: Build and check warnings
Change-Id: I26f56c5c52725dddb70dd8130ad61270eac7a9aa
This is configured from Make by setting up Darwin+Arm64 as a HOST_CROSS
target (which is largely true, as binaries can't be executed on X86_64
machines). On the Soong side, it's a bit blurier, as we don't current
have any other users that are the same OS but not natively executable
(Linux/musl is executable, Windows/x86 is a different OS).
Instead of requiring cc_binary/etc to become multi-architecture-aware
and using something like common_first/MultiTarget, this defaults all
non-multi-architecture-aware modules to be built with both
architectures. It then adds a dependency with the
DarwinUniversalVariantTag so that supporting modules can get the outputs
of the other variant.
Cc uses that dependency tag to run lipo on shared libraries and binaries
so that the output of the x86_64 variant is actually a fat binary
including both architectures.
Bug: 203607969
Test: build sdk-repo targets on a Mac
Change-Id: Icbddb0a177c0ba19d3e0d11f8cf568e0d1ea3245
We do not profile host binaries. Moving to device binaries only helps
saving some disk space as well as shortening build time.
Test: presubmit
Change-Id: I09afb106d0e2ee250b3bc75d9dfd9cb8b6552c97
As they can't built arm64 binaries. All of our master-based builds are
now running on macOS 11 buildbots.
Bug: 203607969
Change-Id: I24c34a8365a399fbe43629ab5a22a1d53e3429b3
This just sets up the toolchain and allows Darwin+Arm64 to be specified
as a HostCross target. These variants will not be exported to Make, or
be installed on a Soong-only build. A future CL will add support for
universal binaries using these variants.
This config is a bit stranger than the regular 64/32 multilib, as it's
two primary 64-bit configs. And on a Darwin/X86 machine, the Arm64
versions are HostCross (doesn't work on the current machines), while a
Darwin/Arm64 machine, either version works (if Rosetta is installed).
Bug: 203607969
Change-Id: Iacaed77d267773672da027cd74917e33fb1c1e94
We're now packaging llvm-windres (aosp/1870074) which can be used as a
substitute for GNU binutils' windres, but we've also removed the last
consumer of .rc files in aosp/1867048 (external/mdnsresponder/).
In the worst case, we can bring back support for .rc files but instead
process them with llvm-windres.
Bug: 203794880
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I30a873537e004b46a87191a932d076a89463c873
Modern Xcode versions only have a single macOS SDK installed anymore, so
we don't need to iterate through our supported versions, only check
whether the current version is supported.
This also makes it so that we can specify "11" (or soon, "12") to
specify all 11.x SDKs, instead of having to update our supported list
multiple times a year. This matches previous years that had multiple
patch releases on 10.14.y, 10.15.y, etc.
Bug: 203607969
Test: build on Mac, changing the supported SDK list
Change-Id: I42715f7e8dfec811de440a435927c14c742dede9
Test: USE_BAZEL_ANALYSIS=1 m adbd
Test: Manually verified config.bzl contains various x86_host flags after
bp2build.
Test: Unit tests
Change-Id: Ie9201ea2be4cd1c6659bea088a797cedbae37403
The Android SDK has been built with Make up until now, monolithically,
then split up into several sdk-repo zip files for different purposes.
The Mac and Windows SDKs really only need to contain the platform-tools
and build-tools pieces, but due to this monolithic sdk zip, we had to
build the whole SDK first.
This adds an `android_sdk_repo_host` module that can build these
platform-tools and build-tools zips.
Bug: 187222815
Change-Id: I55809e1d7447dd65e22461f921b2b8abb6d5f822
We turned this off in local tidy flags, but didn't disable it on global
tidy builds. Let's remove this for now, since the upkeep cost is large
on it, and it also is currently crashing in some cases.
Bug: http://b/199534745
Bug: http://b/194865868
Test: WITH_TIDY=1 m
Change-Id: Ife39ab4949c5baf825efff66326b276c6a2a59f4
