Use objects, not strings, for assertions

[muglug]

It's a big addition, but this would make it slightly easier to track where assertions were being used in the codebase, and removes a lot of checks for $assertion[0] === '!' etc.

[orklah]

This looks really good!

[orklah]

Hi @muglug ! Do you think you'll finish this soon? I'd really like having this in the alpha for Psalm 5!

[muglug]

Yup, should have unit tests passing today

[orklah]

Sorry, my last merge on master broke CI. I'll fix that

[orklah]

Could you add some details on UPDGRADE.md to explain that the old Assertion was renamed and other BC breaks introduced?

[orklah]

every call to getAssertionString is now with $exact to true. Can we drop the param?

[orklah]

This makes so many things looks a lot more clearer! Very cool! Thanks :)

[orklah]

@muglug Is this a BC break regarding projects (including Assert tools) that used empty or !empty as a docblock assertion?

Is there a reason why you didn't kept it as empty?

[muglug]

It can be “empty”, but that should have no impact on the parsing of assertions either way — do you have an example of failing code?

[orklah]

Somehow it still works? https://psalm.dev/r/bb6d82a6a3 https://psalm.dev/r/90da8dba12

I didn't expect that. What is the system that parses assertion strings into Assertion objects?

[AndrolGenhald]

@orklah It's the scanner.

[orklah]

Thanks! I never had to tweak here before... Weird, I thought there would have been a direct link between internal assertion names and user assertions ones. But this answer my question! Thanks both!