Skip to content

Conversation

@zainab-ali
Copy link
Contributor

@zainab-ali zainab-ali commented Jul 11, 2025

This PR adds source code to all failure messages.

This includes weaver expectations such as expect.same and failure, but should also work for user-propagated source locations.

Example

image

Pointing to the failure

For Scala 2, the source position obtained from the SourceLocationMacro corresponds to the opening brace of the expectation. For example, the in:

 expect.same(◊x, y) && expect.same(y, z)

For Scala 3, it corresponds to the closing brace:

 expect.same(x, y)◊ && expect.same(y, z)

We use the position to point to the failing expectation:

expect.same(x, y) && expect.same(y, z)
           ^

@zainab-ali zainab-ali changed the title WIP: Print source code for all failures Print source code for all failures Jul 11, 2025
@zainab-ali zainab-ali force-pushed the source-location-code branch from a05c8a2 to e6100aa Compare July 29, 2025 13:23
@zainab-ali zainab-ali force-pushed the source-location-code branch 5 times, most recently from ae81b78 to 1b99541 Compare August 1, 2025 17:32
@zainab-ali zainab-ali force-pushed the source-location-code branch from 1b99541 to e1fae77 Compare August 1, 2025 17:35
@zainab-ali zainab-ali marked this pull request as ready for review August 1, 2025 17:40
Copy link
Collaborator

@Baccata Baccata left a comment

Choose a reason for hiding this comment

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

Great stuff overall ! Just a nitpick and a question

case LoggedEvent.Error(msg) => msg
}) { actual =>
expect.same(actual, expected)
expect.same(expected, actual)
Copy link
Collaborator

Choose a reason for hiding this comment

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

mmmmm, not your fault as I should probably pay closer attention to earlier reviews, but this is making me eyebrows . I'm pretty sure that unit considers the second argument to be the expected one. Are we differing from it ?

Even our error messages seem to validate that expected should come second 😅

Copy link
Contributor Author

@zainab-ali zainab-ali Aug 12, 2025

Choose a reason for hiding this comment

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

It wasn't something that crept into recent PRs. It was (expected, found) before the refactor, as seen in the old repo, so I kept it the same when doing the rewrite.

MUnit's assertEquals is (found, expected), as shown in the source code, so is unfortunately the opposite.

It would be great to align the two, but it would be very cumbersome for users to switch everything around. We could recommend people use named parameters (expected = ..., found = ...).

Digging into our error messages, I think they're ok, unless there's something I'm missing? The corresponding test has expected as 1 and obtained as 2, so the error message is correct. The guide also has found as the first argument in the error messages.

I changed the order here because I got very confused at the test error messages in the first place 😅 .

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh well, as long as we're consistent with ourselves, I think that's okay 😅

@zainab-ali zainab-ali merged commit a3cc02c into typelevel:main Aug 14, 2025
13 checks passed
@zainab-ali zainab-ali deleted the source-location-code branch August 14, 2025 17:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants