Fix test packages used in pkg/dartdev/test/native_assets to use @RecordUse instead of @ResourceIdentifer

[sstrickl]

There are new test failures on Prepare package:meta for publish.

The tests

pkg/dartdev/test/native_assets/build_test RuntimeError (expected Pass)
pkg/dartdev/test/native_assets/run_test RuntimeError (expected Pass)

are failing on configurations

unittest-asserts-debug-linux-x64
unittest-asserts-release-linux-arm64
unittest-asserts-release-linux-x64
unittest-asserts-release-mac-arm64
unittest-asserts-release-mac-x64
unittest-asserts-release-win-arm64
unittest-asserts-release-win-x64

An example log:

...
00:30 �[32m+5�[0m�[31m -1�[0m: dart link assets succeeds �[1m�[31m[E]�[0m�[0m

  Expected: <0>
    Actual: <254>
  

  package:matcher/src/expect/expect.dart 149:31       fail
  package:matcher/src/expect/expect.dart 144:3        _expect
  package:matcher/src/expect/expect.dart 56:3         expect
  pkg/dartdev/test/native_assets/run_test.dart 108:7  main.<fn>.<fn>
  ===== asynchronous gap ===========================
  pkg/dartdev/test/native_assets/helpers.dart 204:12  runPackageTest.<fn>
  ===== asynchronous gap ===========================
  pkg/dartdev/test/native_assets/helpers.dart 28:5    inTempDir
  ===== asynchronous gap ===========================
  pkg/dartdev/test/native_assets/helpers.dart 198:10  runPackageTest
  ===== asynchronous gap ===========================
  pkg/dartdev/test/native_assets/helpers.dart 161:5   nativeAssetsTest
  ===== asynchronous gap ===========================
  pkg/dartdev/test/native_assets/run_test.dart 96:5   main.<fn>
  ===== asynchronous gap ===========================
  package:test_api/src/backend/declarer.dart 229:9    Declarer.test.<fn>.<fn>
  ===== asynchronous gap ===========================
  package:test_api/src/backend/declarer.dart 227:7    Declarer.test.<fn>
  ===== asynchronous gap ===========================
  package:test_api/src/backend/invoker.dart 258:9     Invoker._waitForOutstandingCallbacks.<fn>
  

00:30 �[32m+5�[0m�[31m -1�[0m: dart link assets doesnt have treeshaken asset�[0m

00:35 �[32m+6�[0m�[31m -1�[0m: dart add asset in linking�[0m

00:38 �[32m+7�[0m�[31m -1�[0m: �[31mSome tests failed.�[0m



Consider enabling the flag chain-stack-traces to receive more detailed exceptions.
For example, 'dart test --chain-stack-traces'.

stderr:
Unhandled exception:
Dummy exception to set exit code.

--- Re-run this test:
python3 tools/test.py -n unittest-asserts-release-linux-x64 pkg/dartdev/test/native_assets/run_test

After changing the tests to properly pass expectExitCodeZero: true (see CL 385921), the additional information printed on stderr:

00:18 +5: dart link assets succeeds



lib/src/drop_dylib_link.dart:10:4: Error: Couldn't find constructor 'ResourceIdentifier'.
  @ResourceIdentifier('add')
   ^^^^^^^^^^^^^^^^^^
lib/src/drop_dylib_link.dart:13:4: Error: Couldn't find constructor 'ResourceIdentifier'.
  @ResourceIdentifier('multiply')
   ^^^^^^^^^^^^^^^^^^


254

00:21 +5 -1: dart link assets succeeds [E]

  Expected: <0>
    Actual: <254>

So it looks like this is pulling in source files from a test package that expects an older version of package:meta before @ResourceIdentifier was changes to @RecordUse and then trying to compile them using the new version of package:meta in the Dart SDK.

/cc @dcharkes @mosuem

[mosuem]

Interesting. I wonder how we could avoid this in the future. Outside of the SDK, I would recommend pinning package:meta to a specific version, but this is not possible inside the SDK, correct?

[dcharkes]

WDYM with in the SDK? In the SDK package meta is likely pinned via the DEPS file.

In test projects in our own test data, we probably pin package:meta via the respective pubspec files.

The issue I suppose is async rolls between dart-lang/native and package meta into the SDK?

[dcharkes]

As for preventing the redness, did the pkg bots not run during the Dart CI?

[mosuem]

package meta is likely pinned via the DEPS file.

Ah, I thought it is just referenced by path, being in the pkg/ directory.

As for preventing the redness, did the pkg bots not run during the Dart CI?

I don't know - do they not run by default, and if not, why not?

[dcharkes]

As for preventing the redness, did the pkg bots not run during the Dart CI?

I don't know - do they not run by default, and if not, why not?

Bot capacity? Have a chat with @athomas on how to fix that.

[dcharkes]

This requires a roll of this repo into the SDK to make the tests in the SDK go green.

Please note that we do not have any test coverage atm (any new tests failures will not raise any alarms) on https://dart-current-results.web.app/#/filter=pkg/dartdev/test/native_assets/ .

Please do a roll tomorrow @mosuem.

[dcharkes]

Thanks for the roll @liamappelbe !

Verified that the tests are green again.

[athomas]

Please note that we do not have any test coverage atm (any new tests failures will not raise any alarms) on https://dart-current-results.web.app/#/filter=pkg/dartdev/test/native_assets/ .

That page just says there are no failures, but there are passing tests:
https://dart-current-results.web.app/#/filter=pkg/dartdev/test/native_assets/&showAll

[athomas]

As for preventing the redness, did the pkg bots not run during the Dart CI?

They run, they ran on the CL that introduced the failure but the tests passed during the CQ run. I can't explain why, we don't keep logs for passing tests. Possibly, there's some form of flakiness involved.