sway/sway-lsp/tests · sw/sway

GGitHubfix modified in optimisation passes so they converge (#7666)

文件	最后提交记录	最后更新时间
fixtures	LSP: Support multiple workspaces (#7214) ## Description The langauge server now supports multiple workspaces and individual projects in a single server instance. For example, in the sway repo itself, we have 3 large sway project workspaces. Before this change, LSP would only work for the first workspace you opened. Now you can freely move between projects and workspaces. There is a bit of code quality associated with this PR to better reflect the new approach rather than the contained `Session` type that we had previously. ## Other changes * This PR fixes a bug with `forc-pkg` that would panic if it was called from an async context. i.e `forc-lsp` or `forc-doc`. We now check if a `tokio` runtime exists and use that to avoid crashing in these situations. * Document symbols are now collected for more types. We also check that document symbols are present for all files in the std library as well as semantic tokens during the test. ## Checklist - [ ] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers. --------- Co-authored-by: zees-dev <63374656+zees-dev@users.noreply.github.com>	1 年前
integration	fix modified in optimisation passes so they converge (#7666) ## Description This PR fix the `modified` return of some optimisation passes, so we can run optimisations multiple times until they converge. To guarantee that they are correct, we now have an "env var" named "SWAY_VERIFY_FORCE" that forces IR verification and checks whether the modified flag is the same as the comparison of the IR before and after the pass. The flag is being set for all snapshot tests. As discussed, it makes sense to remove the "verify" CLI flag. For this last check, I had to write the "mut" of function and block arguments in the IR; otherwise, the "mutability-tagger" pass would return true, but without any visible change in the IR, the check would always fail. This triggered a LOT of changes, given that we assume everything is mutable by default. On the bright side is that it is now much easier to see improvements to the tagger pass. There are also other small improvements in the form of "TODO", because if Sway can guarantee that a value is never written, we can generate the initial IR already flagging something as immutable. Another big change was the removal of "file-checks" for some IR tests. We already have snapshot tests for them, and given that the snapshot shows the complete diff, it is much easier to see the exact difference of each pass. I left normal comments though. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2 个月前
utils	Bump to 0.71.2 and fix crates.io publish (#7634) ## Summary - Bump workspace and `sway-lib-std` to 0.71.2 after the failed v0.71.1 crates.io publish (only `sway-utils` 0.71.1 made it up; binaries for v0.71.1 are fine). - Fix publish breakage from yanked `core2` (RUSTSEC-2026-0105): `FuelLabs/publish-crates` runs `cargo update` after each crate, which failed on the `multihash 0.17` → `ipfs-api` chain used by `forc-pkg`. - Patch `core2` from the `bbqsrc/core2` git rev and bump `cid` to 0.11.3 so release `cargo update` resolves again. ## Test plan - [ ] CI green on this PR - [ ] Merge and cut GitHub release v0.71.2 - [ ] Confirm `publish` job completes on crates.io - [ ] Optional: `cargo install forc --version 0.71.2` smoke test	3 个月前
lib.rs	Refactor and tidy up `std` tests for execution speed and discoverability (#7669) ## Description This PR represents a major cleanup and refactoring of tests covering `std` and closes #7617. The PR brings: - consistency: all `std` tests are now in `in_language_tests` and not scattered anymore on four different places (`sway-lib-std`, `stdlib`, `sdk-harness`, and `in_language_tests`). - better discoverability: test Sway files have the same name as their tested modules and appear in IDE file searches next to each other. - better execution speed: by removing redundant test projects and grouping existing `in_language_tests` projects per tested `std` modules we reduced the number of projects to compile and tests to run noticeably gaining on test execution speed. The above benefits are gained via: - porting E2E `stdlib` tests to `in_language_tests` and deleting redundant test projects. - porting `std` related SDK harness tests to `in_language_tests` and deleting redundant test projects. - moving 11 unit tests found in `sway-lib-std` to `in_language_tests` and forbidding writing unit tests in the `sway-lib-std`. `std` test must now be situated in in-language tests. The consequence of this decision is losing the possibility to test private members. Currently this is not a limitation. If it ever becomes, we can allow intentional testing of private members, e.g., via special test naming conventions or some other approach. - restructuring `in_language_tests` for better discoverability and test execution speed. The guidelines for writing in-language tests are fully documented in the accompanied README.md. The PR also acknowledges the control and flexibility we gained by introducing `run_in_language_tests.sh`. Although initially introduced as a workaround for #7613 the script proved to be more powerful and useful for development than using plain `forc test` of the workspace. Therefore, the PR removes TODOs related to switching back to `forc test`ing the whole workspace. The new structure of in-language tests reflects the `std` module structure. Having test modules being named the same as their tested `std` modules allows for quicker finding of both the module and its tests in IDEs. The new convention also removes the verbosity of the `_inline_tests` and `_contract_tests` prefixes. It turned out that this verbose additional information didn't bring a concrete benefit, while producing visual clutter. The faster test execution is noticeable. By grouping several in-language projects into a single one we have less `std` compilations. Number of initial in-language projects dropped from 72 to 47 causing parallel execution time of whole suite to drop from ~55s to ~40s. Similarly, we deleted the following number of other test projects that were redundant and already covered by in-language tests: 1. 35 out of 39 `stdlib` test projects from E2E tests, 1. 8 SDK harness test projects. - Closes #7617. ## Checklist - [x] I have linked to any relevant issues. - [x] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [x] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [x] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [x] I have requested a review from the relevant team or maintainers.	2 个月前
nextest.toml	Use cargo-nextest with retries for flaky LSP test (#6521) ## Description This PR introduces [`cargo-nextest`](https://nexte.st/) to improve our test runs. We've configured 2 retries for the go_to_definition_for_paths test, which has been intermittently failing. The LSP CI workflow has been updated to use `cargo-nextest`. Should mitigate #6029 until we get to the root cause why these tests are flaky. ## Checklist - [x] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.	1 年前