[hooks] Support code assets in `dart test -c cli --target-sanitizer`

[dcharkes]

Follow up of #63372.

• We'll add a dart test -c cli that will use dart build cli under the hood. It will not properly support sanitizers for now.

We'll use sanitized dylibs from build hooks, and a sanitized aotruntime.

However, since the AOT snapshot is appended, none of the compiled Dart symbols will show up in sanitizer error messages.

To support sanitizers and build hooks together, we'll need to:

• [dartdev] dart build cli support a separate aotruntime mode? #63435
• And then wire up the dart test -c cli to accept the --target-sanitizer flag.

Use case:

• FFI safety: add valgrind and memory-pressure testing google/webcrypto.dart#278

[HamdaanAliQuatil]

@dcharkes #63435 is now in, so I’d like to take this next.

I checked the current package:test implementation. _compileToCli already invokes dart build cli and maps vm-asan, vm-msan, and vm-tsan to the corresponding --target-sanitizer argument. On Linux, the SDK now includes the matching dartcliruntime_* artifacts.

The remaining work looks like:

• allow Compiler.cli for vm-asan, vm-msan, and vm-tsan, while keeping exe as the default;
• pass the existing sanitizer environment defaults when launching a CLI bundle;
• update the compiler/runtime tests to check for the corresponding dartcliruntime_* artifact;
• add -c cli coverage for the sanitizer runtimes.

I think the user-facing command should remain dart test -c cli -p vm-asan (and similarly for MSan/TSan), with package:test translating that internally to dart build cli --target-sanitizer=....

I’m planning to keep the compiler/runtime coverage in dart-lang/test. Once that revision rolls into the SDK, I’ll add a full hook-built end-to-end case to the SDK’s native-assets tests, since that suite already has the relevant fixtures and dependency overrides. Let me know if you see a reason to keep that coverage in dart-lang/test instead.

[dcharkes]

• pass the existing sanitizer environment defaults when launching a CLI bundle;

What does this mean?

Yeah we need to set up the plumbing and then add then adding a test in the SDK sgtm.

You might want to to set up the plumbing in package:test and then write the test in the SDK immediately and use a git override in the package config (or a DEPS test_rev update + a path dependency to the pulled in package test) to ensure everything works before landing package:test support.

Also for the package:test PR you probably want to add a bool similar to the already existing supportsCliCompiler. Something like supportsCliCompilerSanitizers with the first dart release on the dev branch that contains 56d533f.

Thanks for the help @HamdaanAliQuatil! 🙏

[HamdaanAliQuatil]

pass the existing sanitizer environment defaults when launching a CLI bundle;

What does this mean?

I meant _environmentFor(platform) in VMPlatform. For vm-asan, vm-msan, and vm-tsan, it supplies halt_on_error=1:exitcode=6:symbolize=1 when the corresponding sanitizer environment variable isn’t already set.

the Compiler.exe path passes that environment to Process.start, but the Compiler.cli path currently doesn’t. I’ll make the CLI launch use the same helper while preserving any options supplied by the user.

I’ll start with the package:test plumbing and add supportsCliCompilerSanitizers, gated on the first dev SDK containing 56d533f. While that change is still open, I’ll wire up the SDK integration test using a local package-config/path override so we can verify the complete hook-built native asset path before landing the package:test support.