Skip to content

Allow #[test_proc] to expect specific assertion failures #2109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

rw1nkler
Copy link
Contributor

@rw1nkler rw1nkler commented May 3, 2025

This commit introduces the ability to specify that a test proc is expected to fail on a particular assert! or fail! in the DSLX interpreter. The #[test_proc] attribute accepts an optional expected_fail parameter. with the label marking the failure. If a failure occurs with the matching label, the test is treated as successful.

The choice to implement this as an attribute, rather than a built-in, as discussed in #1071 (comment) was motivated by cases where there's no clear location to “catch” the failure. For example, a test that spawns a proc containing only a single fail! statement.

The functionality is implemented by storing the expected_fail value in the TestProc object. When an assert! or fail! is handled in the DSLX interpreter, the label of the failure is attached to the error using an absl::Status payload. This is then compared in RunDslxTestProc against the stored label in the TestProc.

Resolves #1071

@proppy
Copy link
Member

proppy commented May 7, 2025

/cc @cdleary who originally commented on the preferred syntax: #1071 (comment)

@proppy
Copy link
Member

proppy commented May 7, 2025

curious if that's something that regular SystemVerilog/UVM support, and what this would ultimately map to if we were generating SV test benches from DSLX tests.

@rw1nkler
Copy link
Contributor Author

rw1nkler commented May 9, 2025

curious if that's something that regular SystemVerilog/UVM support, and what this would ultimately map to if we were generating SV test benches from DSLX tests.

I believe there is no option to ignore the $fatal statement in SystemVerilog. However, if support for fail! and assert! is extended to allow the generation of a signal upon failure (as proposed in google/xls#1352), the testbench could include logic to respond accordingly by either triggering a failure or allowing the test to pass based on the context.

@rw1nkler rw1nkler force-pushed the 76623-expected-fail branch from 2b6d318 to 48f880d Compare May 9, 2025 13:47
@meheff
Copy link
Collaborator

meheff commented May 12, 2025

@richmckeever mind having a look at this as it touches on the frontend. The feature is very nice to have.

@rw1nkler rw1nkler force-pushed the 76623-expected-fail branch from 48f880d to 533c6ef Compare May 13, 2025 17:59
@rw1nkler rw1nkler force-pushed the 76623-expected-fail branch 3 times, most recently from fd95467 to 0cf4893 Compare May 19, 2025 15:08
@rw1nkler
Copy link
Contributor Author

I also modified the DSLX formater accordingly

@rw1nkler rw1nkler requested a review from richmckeever May 19, 2025 15:10
@@ -533,6 +533,68 @@ proc doomed {
IsTestResult(TestResult::kParseOrTypecheckError, 0, 0, 0));
}

TEST_P(RunRoutinesTest, TestProcExpectedToFailOnAssert) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add one more test, where we assert with an unexpected label and the test result is a failure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added separate tests for both assert! and fail! macros that check whether the failure on incorrect label is treated correctly.

@rw1nkler rw1nkler force-pushed the 76623-expected-fail branch from 0cf4893 to 14ab842 Compare May 27, 2025 13:43
@rw1nkler rw1nkler requested a review from richmckeever May 27, 2025 13:46
rw1nkler added 2 commits May 28, 2025 12:23
Enables writing tests that are expected to fail via `assert!` or `fail!`.
The attribute value must match the label provided in the failing assertion.

Signed-off-by: Robert Winkler <[email protected]>
@rw1nkler rw1nkler force-pushed the 76623-expected-fail branch from 14ab842 to d731ed2 Compare May 28, 2025 10:23
@rw1nkler rw1nkler requested a review from proppy May 28, 2025 10:25
absl::StatusOr<TestProc*> ParseTestProc(Bindings& bindings);
absl::StatusOr<TestProc*> ParseTestProc(
Bindings& bindings,
std::optional<std::string> expected_fail_label = std::nullopt);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional: = std::nullopt isn't needed, since all the uses already specify the fail label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[DSLX] Feature: Add #[test_fail] and #[test_proc_fail]
5 participants