[v2] Fix multiline natspec comment lexing

[teofr]

Fixes #1469

Goes from matching multiline NatSpec comments with r#"/\*\*[^\*]*\*+([^/\*][^\*]*\*+)*/"# to r#"/\*\*([^/\*][^\*]*)?\*+([^/\*][^\*]*\*+)*/"#.

The main difference is that immediately after the /** a character different than / is expected.

A sourcify run over all the chains shows a few errors, but I think these are different. Still, a lot less failing contracts than before.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5343164

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[teofr]

Just as a note, while thinking on ways to solve this one option was to use a different mode for parsing multiline NatSpec comments. I don't think it's worth it for now, but it could be interested for our parser to give NatSpec comments a structure.

[teofr]

After some experimenting with Remix, it seems a comment with 3 asterisks (/*** */) is not considered a NatSpec comment, I tried adding that modification here but it differs too much from the V1 lexer. Maybe worth it doing it on a separate PR and fix the V1 lexer?

I think it's enough to remove the ? from the regex (ie r#"/\*\*[^/\*][^\*]*\*+([^/\*][^\*]*\*+)*/"#)

[OmarTawfik]

🚀