How about adding test linker scripts to integration tests?

@lapla-cogito
Quick clarification: are you suggesting moving test_section_command_with_filename() to the integration tests, or adding a new integration test that includes a test linker script?

I intend the latter. Place the test code (in this case, likely a linker script and a C source file) under wild/tests/sources. After that, add the necessary test directives to the source file (see the beginning of wild/tests/integration_tests.rs for details), and then add the name of the newly added source file to integration_test(). Once this is done, running cargo test will execute the newly added test.

Is it okay now? Since it’s my first time, there might still be some changes needed.

Might be worthwhile installing typos so that you can run it before you upload the change. I have a script that gets run whenever I'm uploading a change. It runs typos, runs the tests in a few different modes etc.

My script, in case you're wondering currently looks like the following.

#!/usr/bin/bash
set -e
typos
cargo +nightly fmt --check
cargo clippy --all-targets --features mold_tests -- -D warnings
cargo clippy --no-default-features --all-targets -- -D warnings
cargo clippy --features plugins
cargo test --features plugins
if [ -z "$SKIP_MOLD_TESTS" ]; then
    WILD_TEST_CROSS=aarch64 cargo nextest run -v --features mold_tests
fi

Or at least that's the wild-specific part of the script. I also have other more generic scripts that grep the diff of changes for things like "DO NOT SUBMIT", notify me of any added files, etc.

Where possible, it's good if you can make the title of the PR what will go into the release notes. If you prefix it with "feat:" then it'll go into the features section. I'll usually edit it when I'm merging the change if it doesn't seem quite right, but I sometimes forget.