diff options
| author | Yong He <yonghe@outlook.com> | 2025-07-02 14:15:58 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-07-02 21:15:58 +0000 |
| commit | 54a5d7f0056b4a846c790e7e019b9b5e74f76a98 (patch) | |
| tree | b7560e27ab93bfe7063ab085684bb6290418ddce /.github/copilot-instructions.md | |
| parent | bee3142ce4564d7cb6ec0af43b4ffdcae1d2e68d (diff) | |
Run full check on merge_queue, but not on push. (#7596)
* Run full check on merge_queue, but not on push.
* Fix.
* Update copilot instructions.
Diffstat (limited to '.github/copilot-instructions.md')
| -rw-r--r-- | .github/copilot-instructions.md | 31 |
1 files changed, 28 insertions, 3 deletions
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 17523888c..9afc79389 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -2,16 +2,17 @@ To configure cmake, run `cmake --preset default --fresh`. To build, run `cmake --workflow --preset debug` or `cmake --workflow --preset release`. +Build instructions can be found in docs/building.md ## Formatting Your PR needs to be formatted according to our coding style. -Run `./extras/formatting.sh` script to format your changes before creating a PR. +Run `./extras/formatting.sh` script to format your changes before submitting them. ## Labeling your PR All PRs needs to be labeled as either "pr: non-breaking" or "pr: breaking". -Label your PR as "pr: breaking" if you are introducing public API changes that breaks ABI compabibility, +Add the "pr: breaking" label to your PR if you are introducing public API changes that breaks ABI compabibility, or you are introducing changes to the Slang language that will cause the compiler to error out on existing Slang code. It is rare for a PR to be a breaking change. @@ -19,4 +20,28 @@ It is rare for a PR to be a breaking change. Your PR should include a regression test for the bug you are fixing. Normally, these tests present as a `.slang` file under `tests/` directory. -You will need to run your test with `slang-test tests/path/to/your-new-test.slang`.
\ No newline at end of file +You will need to run your test with `slang-test tests/path/to/your-new-test.slang`. +You will need to build the `slang-test` target first. +Note that your execution environment does not have a GPU, so you can't run any tests that requires a GPU locally, for example, +you won't be able to run a shader test using D3D12, Vulkan, Metal or WGSL. + +If the changes you are making is not specific to a particular GPU target, you can craft your test case to run on the CPU +by writing the following as the first line of your test shader: + +``` +//TEST:COMPARE_COMPUTE(filecheck-buffer=CHECK):-output-using-type -cpu +``` +See `tests/language-feature/lambda/lambda-0.slang` for a full example. + +Or you can craft your test to run with `slangi` (byte-code interpreter), such as: + +``` +//TEST:INTERPRET(filecheck=CHECK): +void main() +{ + //CHECK: hello! + printf("hello!"); +} +``` + +If you are working on a GPU specific feature, don't try to run the test locally, just leave your PR to the CI for verification.
\ No newline at end of file |
