Imported from eclipse-oniro-mirrors/arkcompiler_runtime_core (static_core/plugins/ets/stdlib/AGENTS.md). Install upstream with npx skills add eclipse-oniro-mirrors/arkcompiler_runtime_core --skill stdlib. Copyright stays with the author.

ETS Standard Library Guide

Project Overview

This directory contains the ArkTS-Sta standard library within ArkCompiler Runtime Core, located at static_core/plugins/ets/stdlib/.

Directory Routing

Module configuration: stdconfig.json (defines the "std" to "ets/stdlib/std" path mapping)

Build and Verification

For build commands, test framework usage, and urunner invocation, see docs/knowledge/build_and_test.md. Build commands are executed from static_core/ (i.e., ../../../), not from this subdirectory.

Verification by Task Type

Completion Criteria

A task is considered complete when:

• The behavior has been implemented
• Relevant builds and tests have passed, or reasons for inability to verify have been documented
• Test cases in the ignore list are allowed to fail if they have known issues
• The final response includes: list of changed files, verification commands and results, and remaining risks

For behaviors involving real hardware, devices, display, or service integration, board-side evidence must be provided.

Knowledge Routing

Before making changes, locate the relevant code paths by scenario and read the corresponding knowledge documents. Before making changes, you must declare in your response: the task category, the knowledge documents you have read, and the constraints extracted from them.

Project Constraints

Architectural Invariants

• With the exception of arkruntime/ and std/math/consts/, all std/ directories are implicitly imported. The frontend compiler automatically inserts import directives, allowing user code to use them directly — do not change implicitly imported modules to explicit imports or vice versa
• Native calls involving third-party C libraries (PCRE2, ICU4C, etc.) must go through ANI bindings to native/core/ — third-party library execution times are unpredictable and their source code cannot be modified, so they cannot use intrinsics
• High-frequency hot-path native calls use intrinsics (YAML bindings), but the intrinsic execution time must be reasonable — see docs/knowledge/performance.md for rationale
• The declaration order of fields in an ETS class does not necessarily match the actual memory layout of the corresponding native mirror class (EtsType*) — the frontend compiler and runtime reorder and align fields for layout optimization. When adding or modifying mirror class fields, you must verify the field offsets match between the managed class and the C++ mirror class via offset tests. Reference: static_core/plugins/ets/tests/runtime/types/ contains mirror class offset self-tests (e.g., ets_map_test.cpp — see MapMemoryLayout test using MirrorFieldInfo::CompareMemberOffsets)

Do Not

• All .ets files must include the Apache 2.0 license header (year 2021-2026). Shell scripts use the # prefix
• Do not directly edit files that begin with // NOTE: autogenerated file — you must modify the corresponding template instead (see docs/knowledge/code_generation.md)
• Do not return from a finally block
• Do not return a constant from main() — you must return myTestsuite.run()
• Do not unconditionally promote frequently called APIs to C++ intrinsics or irtoc implementations (see docs/knowledge/performance.md)
• After modifying .ets files, you must rebuild before running tests
• Template changes and generated files must be committed together
• Do not add or modify mirror class fields without adding/updating corresponding field offset tests — see Architectural Invariants above; reference tests are in static_core/plugins/ets/tests/runtime/types/ (e.g., ets_map_test.cpp MapMemoryLayout using MirrorFieldInfo::CompareMemberOffsets)

Ask Before

• Modifying the public API signatures or semantics of implicitly imported modules (std/core, std/containers, etc.) — this affects all ArkTS users and downstream impact cannot be fully assessed
• Deleting or renaming exported APIs — these may be compile-time dependencies for other modules or external code
• Adding or modifying intrinsic registrations (ets_compiler_intrinsics.yaml, etc.) — this affects safepoint/GC behavior and requires performance evaluation
• Adding third-party library dependencies — not all third-party libraries are approved for use; license, security, and size impact must be reviewed