Add debugger extension tests

[MrSarius]

This PR adds tests for #2219. The VS Code extension has not had any tests yet. The tests only cover code that was touched by me.

I have added the tests to the compilation_on_android_ubuntu.yml workflow. The first run will take about two hours, since LLDB is built from scratch. Later, the build should be cached and the whole job should not take more than three minutes.

Core of the PR is an integration test that boots up vs code and lets it debug a test WASM file.

Run Tests locally

Download the LLDB build for your platform from my pipeline.

cd ${WAMR_ROOT}/test-tools/wamr-ide/VSCode-Extension/resource/debug
wget ${LLDB_FOR_YOUR_PLATFORM}.tar.gz -O lldb.tar.gz
tar -xvf lldb.tar.gz
cp -R wamr-lldb/* ./${YOUR_PLATFORM}

Make sure wasm32-wasi target is available.

rustup target add wasm32-wasi

Build iwasm with source debugging feature

cd ${WAMR_ROOT}/product-mini/platforms/${YOUR_PLATFORM}
mkdir build && cd build
cmake .. -DWAMR_BUILD_DEBUG_INTERP=1
make

Note: On MacOS M1 environment, pass the additional -DWAMR_DISABLE_HW_BOUND_CHECK=1 cmake configuration.

Install npm dependencies and run tests.

cd ${WAMR_ROOT}/test-tools/wamr-ide/VSCode-Extension
npm install
npm run test

[Zzzabiyaka]

maybe add it to nightly_run instead of per-PR if it's 2hrs?

[eloparco]

LLDB version doesn't get updated that often, if we cache it (the first time a PR for the update is created), it should be fine

[MrSarius]

I also think it should be fine.

The LLDB patch file was changed four times in the last 2 years.

[Zzzabiyaka]

Thank you got it

[TianlongLiang]

To run tests locally, the node version has to be 16.x+(GitHub Actions use 18.16.0), is there a way to add it in package.json to ensure the user's node meets the requirement?

What I can think of is to add the engines field in your package.json file like:

    "engines": {
        "vscode": "^1.59.0",
        "node": "^16.0.0"
    },

and add engine-strict option in the new .npmrc file:

engine-strict=true

This will force npm to err for node versions lower than 16.x. I think it's better to err by setting engines rather than warn by setting devDependencies

What do you think? Is there any other way to achieve this?

[MrSarius]

Hi @TianlongLiang,
Thanks for the feedback. All Done!

[wenyongh]

LGTM

[Zzzabiyaka]

does it worth adding the same tests for macOS CI job if it's supported? @MrSarius

[MrSarius]

In general, of course, the integration tests could also find major problems in the LLDB build (crashes etc.). That could be helpful for all platforms that are suppported.

But in the context of the extension, that doesn't add much value compared to the extra effort it means (building and caching LLDB for Macos)

[TianlongLiang]

Hi, @MrSarius, after the recent update of VS Code, for version above 1.86.0, it seems that the format conversion in formatters/rust.py failed, therefore it returns the raw format and assertion fails during the value check process.

      The Deque summary string looks different than expected
      + expected - actual

      -alloc::collections::vec_deque::VecDeque<int, alloc::alloc::Global> @ 0xfff1c
      + (5) VecDeque[1, 2, 3, 4, 5]

For fixing the CI error, could you please let me know your opinion? Do you think this is mainly a VS Code bug? If so, maybe we can safely ignore it for a while and use the fixed VS Code version. Or is it a major interface change that needs modification on our side?