Depending on a static_library from Rust fails because the correct
link directory path is not passed to build_rustc_target.py. This
fix adds link paths from every one of the dependecies found in
non_rust_deps.

This is not ideal since it doesn't work with source_set or any
shared library that has transitive dependencies.

TEST=Build, CQ, and Rust crate that tests scenario.
     fx run-test static_library_tests

Change-Id: I42c2d07e68d5f7a3d76c0edacbcd0d81f50c4993

MI4-2413 #done

TESTED=fx run-test discovermgr_tests

Change-Id: Id230a9b1a4b80335fe36b2fa492e3033ac181598

Allocating the memory buffer for RandomMemcpy can be very slow. In
some manual testing on Eve, the buffer allocation appeared to take 4-8
seconds.

This is with a debug build which uses -O0, and the std::vector
constructor will produce code that does a function call for every byte
in the 128MB buffer.  (In release builds, the compiler will optimise
that to a memcpy().  When unoptimised, it's very slow.)

Optimize the buffer allocation, by using a primitive array, rather
than a std::vector. We fill the array before reading from it, to
ensure that we do not cause any reads of unitialized memory.

The net result of the optimization is that the time to run the
benchmarks in "unit-test-mode", on my Eve, drops from ~2 minutes to
~30 seconds.

Bug: FLK-124 #done
Test: /pkgfs/packages/zircon_benchmarks/0/test/zircon_benchmarks (on eve)
Test: /pkgfs/packages/zircon_benchmarks/0/test/zircon_benchmarks -p (on eve)
Change-Id: I449a304a60ccee6a137e9371ca4455b8840fedde

MI4-2367 #comment Scaffold for discovermgr with DiscoverManager
implementation and ModuleOuput skeleton

TESTED=fx run-test discovermgr_tests

Change-Id: If2948bc83eeec070d1f976bd76a2a514c8c86dd8

Sort keys, no whitespace

Change-Id: Iacf53e608092f3ce6b40bed14a63329ea5f590f3

Tracked by: TC-485

Change-Id: I38c6acf8fda78d167277cc13e6760d5db4f110b2

The compiler doesn't actually support -fsanitize=fuzzer builds
that supply their own main function instead of getting it from
libfuzzer.  This was not noticed because build-tests isn't getting
run on bots.

Bug: BLD-481 #done
Change-Id: I2575cf987ff083843b22edebb28bd7bcf2525ae3

The FIDL bindings don't deliver NUL-terminated strings.

Bug: BLD-464
Change-Id: I68b7e3e9ceb9c44de5a89cf0f3b88bc4bf6d929e

Change-Id: Ie50a79bc98d6df42c4a52cdaa1abe1d389ff4b15

"URL" is the new universal terminology.

CF-742 #done

Change-Id: Ib73850b2023b1fb05efdb0c51b2e6f6d0cb6d89d

The implementations weren't being compiled in, so why have the headers.

Change-Id: I58f8980e943aad253e65514998bac42c6c64058a

This CL renames the `fuzz_target` GN template to `fuzzers`.  This is
closer to both Zircon and libFuzzer's terminology.

Test: fx set core.x64 --with //bundles:tests --fuzz-with asan
Bug: BLD-430
Change-Id: I79540e844f01d6abe2cee154544b1a480d8ea670

... and context-switch tests

PT-158 #done

Change-Id: I5023f7cfbb073ae7999fcdcd59d2d9370be75963

Change-Id: Iec766864267074711f7dcc298a037a4288ac7489

Move the resize tests into their own translation unit ant test target.
Use zxtest instead of unittest in the new tests.
Create set of utils for common tasks in the resize tests.

Utils treats devices as objects(Using RAII mechanics to close handles
and perform cleanup). This reduces the boilerplate of manually creating
the requests for fvm_* and such free functions, and makes the test more
readable in terms of what actually matters.

New test target is named fvm-integration-test.

TEST=fvm-test,fvm-integration-test

Change-Id: Ie88fb94c61affe188492e1de2991079cffe91d3d

"fx run-host-tests -z" used the removed command "build-zircon" before
running tests. Update it to use the normal "build" which now builds
zircon too.

Change-Id: Iaaccb01f9155e3989c68c55612cedf0d92ee1224

FIDL source files must be named `*.fidl` and if source files are
named `*.test.fidl` then the library using it can only be used in
test code.  So the fidl_library() template automatically sets
`testonly=true` if its sources list include any `*.test.fidl`.
It's not allowed to override this with explicit `testonly=false`.

Change-Id: I7bb79327be678efbfd293b9fa2baaad55832c9df

This avoids the extra DT_NEEDED entry even in cases where libc++.so
isn't needed. This is also consistent with Clang driver implementation
which uses --as-needed around libc++.so.

Bug: ZX-4099
Change-Id: I76475896b7ea2c825a97f28b7b09e53228b468c6

We can't assume that there will always be a block device. For now, we
can assume that there will always be a platform-bus driver bound.

It would be better if we created a fake devfs for these tests but since
device discovery is going to signficantly change in the near future this
should be good enough for now.

ZX-4090 #done

Change-Id: I668e6a13ec273f83d13654ba692ea92763fc41b8

Add information about running the examples using fx commands.

PiperOrigin-RevId: 246914905
Change-Id: I6489354d5941671f6f04682e548d32d0bee28fef

This are the final things in /garnet/bin/auth so we also delete it
(yey!).

AUTH-196 #comment

Change-Id: I0d73f3c20d4195de70799f28ce1183395baac4a6

This is the start of the central state machine which makes requests to
omaha.  This is the initial skeleton if the async flow of performing a
single update check (and subsequent update if one is returned by Omaha).

Bug: PKG-465
Test: fx run-test omaha_client_lib_tests
Test: ran prototype client (not in this CL) with Omaha service

Change-Id: Ic6e07f76bd30f903ee232f61a20ca1f595adeb74

Change-Id: I7e3915b69d321fb2f2b2d2598259ee6dc2eed9b4

This causes union fields to be generated using the same logic as struct
fields, so that arrays and strings are properly handled. Note for now
that vector fields are excluded from unions, as they actually generate
two fields (a pointer and a count) which does not interact well with
unions.

Change-Id: I69a36903390740d5443f5e3ff0d00d3e49e423f8

This change implements a very simple command line tool/uapp application to consume the
disk objects for minfs and recursively iterate over all of them.
Please note that this is not interactive at the time being, but is implemented
as a first implementation of the disk-inspector tool. It is a good way to
test the different apis of the disk-inpector library.

Testing: The application itself is pretty dumb and doesn't need unit tests.
          The unit tests for minfs backend are already added as part of the change:
          https://fuchsia-review.googlesource.com/c/fuchsia/+/277175
Change-Id: Icd211c30bdb2c82c9f242447d8fddc5d7620c323

Test: CQ

Change-Id: I0b8a33851af712c41c0bcf84d05a150a29e99730

This makes it much easier to compare failing test output against the
reference, as well as to derive new reference outputs from the test log
when tests are updated.

Change-Id: I7af722007b39bf08ff602636ed6a3562c617aa03

Change-Id: I0a6b422086d82e61c3761d9abc3a0b2e147da3df

ZX-3736

Test: stack-test
Change-Id: Ib7a55021bf5790352a451a34a5cad1e74fda780b

This updates the ISP test fidl interface to comply with abarth's
fidl rules.

TEST: No functionality change.
Change-Id: I6660a9bf47e66ba7337c95245f9e7ade5f9dfb3d

Change-Id: If6d9f751f9beadf51bddd584eb3f8cb7d5511ef7

* apparently RunLoopWithTimeoutUntil() is bad because the default timeout
isn't guaranteed to be enough on some bots so instead we rely on the
infra timeout they give to each test
* we don't check the return value RunLoopUntil() in anticipation of https://fuchsia-review.googlesource.com/c/fuchsia/+/280471

TESTED=`fx run-test feedback_agent_tests`
TESTED=`fx run-test crashpad_agent_tests`

Change-Id: I491252ef6a3e3f51f418ef5e57d3f426411e54f6

This changed from RGBA in
https://github.com/brendan-duncan/image/commit/f3d07a74d17d0004d88fc1043042df9111eb3b6f

Also added a test for this regression.

Issue: https://github.com/brendan-duncan/image/issues/92
Test: fx run-host-tests sl4f_client_tests
      end-to-end test
Change-Id: If8c82f9d5479d16e7c41845eb001d6ac8068ea27

Step #1's local testing was misconfigured and failed to test the
step #2 integration build properly as the bots do, so a trivial
bug slipped through.

Bug: ZX-3365
Change-Id: I331b3b989125c5982632d310daa8b7d512a49faf

This CL extends the host test for host fuzzers to also run the python
unit tests for 'fx fuzz'.

Bugs: SEC-170
Test: fx set core.x64 --with //src/fuzzing:tests
      fx run-host-test fuzzing_host_test
Change-Id: Ic2568e5603b34d35a94ebe85161f476f7854c330

We use the __TA_xxx macros to annotate code for clang's thread safety
analysis features.  The thread safety analysis feature works by
comparing the annotations on types with the annotations on code using
those types and generating a warning if the code is identified that is
inconsistent with the annotations or the defined semantics of the
annotations.  We frequently use these annotations to describe the
relationship between code and types from the C++ standard library, such
as std::mutex.  These types are annotated in the libc++ standard library
implementation if the preprocessor define
_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS is set.

In the Fuchsia build, we always set -Wthread-safety and -D_LIBCPP_...
compiler flags together so the annotations are consistent internally.
Some SDK customers use the fuchsia SDK and -Wthread-safety flag without
setting the preprocessor define as they use other libraries which use
the C++ standard library types in ways incompatible with thread safety
analysis.  This causes issues when compiling code that uses the
__TA_xxx macros with types like std::mutex.

This updates the __TA_xxx macros to only enable annotations if we can
tell that C++ standard library types are annotated (using the
_LIBCPP_... macro) or if we're in kernel code that we always control.

This also updates zircon/kernel code to use the non-public macros
defined in zircon/system/private so that they are enabled even when
libc++ is not involved.

ZX-4091 #done

Change-Id: I74910f6963d79bd2a53cf5d89a183252c5b58e7e

Tracked by SPN-19.

Testability: HotSort library and test compile and run.
Change-Id: I6a80c97057493c3f967cc4eef30691e82d18ad16

Tracked by SPN-22 and SPN-19.

Blocks tests SPN-17, SPN-18.

Change-Id: I4bd95681b26b81e3521c518b4d0894730e5c23ce

Tracked by SPN-19.

Testability: not yet part of build.
Change-Id: I04c73606b03191d2c6e4f2048f329af848c8f5fb

The double free would occur if
1) some thread invoked Cancel() to queue destruction of a ProxyIostate,
   and
2) before that packet was processed, the ProxyIostate's handler ran and
   decided to destroy itself.

Bug: ZX-4060
Change-Id: I3b9c7275c4e0cd2dc3a6c6cd2d2376c947eb627a