Skip to content
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

Replace Boost-based Natspec test case with one derived from SyntaxTest #14506

Merged
merged 8 commits into from
Sep 11, 2023

Conversation

cameel
Copy link
Member

@cameel cameel commented Aug 21, 2023

Fixes #14433.
Depends on #14505.

I recommend reviewing commits individually in this PR. There's a lot of file moves and simple changes that can be easily skimmed, but this is not apparent in the unified diff.

@cameel cameel self-assigned this Aug 21, 2023
@cameel cameel changed the title Replace Boost-based Natspec test case with one derived Replace Boost-based Natspec test case with one derived from SyntaxTest Aug 21, 2023
@cameel cameel added the has dependencies The PR depends on other PRs that must be merged first label Aug 21, 2023
@cameel cameel requested review from nikola-matic and removed request for ekpyron August 21, 2023 11:16
@nikola-matic
Copy link
Collaborator

Oh wow, how long did this take to move from cpp to isoltest? 🚀

@cameel cameel force-pushed the extracted-natspec-json-tests branch from 5e232ea to 3bdc92f Compare August 21, 2023 11:22
Copy link
Member Author

Choose a reason for hiding this comment

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

This one and return_param_amount_differs.sol were originally in syntaxTests/natspec/invalid/, even though they work just fine. The number of return parameters does not differ like the name implies and perhaps it should. Need to investigate.

@cameel
Copy link
Member Author

cameel commented Aug 21, 2023

Oh wow, how long did this take to move from cpp to isoltest? 🚀

If you mean moving the test cases, not much. I spent a few hours writing a test parser. Later I ran it and it did all the work for me (see #14433 (comment)). That was actually the easiest part :)

I spent more trying to actually reuse isoltest base classes. I went through a few dead ends in the process. Still, it wasn't by itself that hard and I was actually sitting on this being 90% finished, and waiting for my other refactors to go in.

Then it turned out that this last 10% is more annyoing than expected and some features I needed for one more complex test case could not be easily reused. So before the weekend I rewrote the test case on top of SyntaxTest (see #14505) and got this.

Copy link
Collaborator

@nikola-matic nikola-matic left a comment

Choose a reason for hiding this comment

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

I'll go over the SolidityNatspecJSON.cpp to double check whether you've moved all of the tests, but that will take some time unfortunately.

));

startPosition += 2;
if (startPosition < _line.size() && _line[startPosition] == ' ')
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should this behave as a trim function, or do we always expect a maximum of one whitespace after //?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, I intentionally only strip // . If there's more indentation there, it's a part of the value. In many cases it won't matter, but in some it might. I'm considering moving this helper to some more general location later, so better not to assume that. Actually, even with JSON it might matter if the parser allows multi-line strings (which I think jsoncpp does). And if you want to print the extracted value, it may look weird without whitespace.

test/libsolidity/NatspecJSONTest.cpp Outdated Show resolved Hide resolved
test/libsolidity/NatspecJSONTest.cpp Show resolved Hide resolved
Comment on lines +13 to +14
// ----
// ----
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why are there two of these?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's the feature I added in #14505. CommonSyntaxTest now supports extra expectations after the error list and these are separated with an extra // ----. The base class stops reading from the stream there and the derived class can continue, interpreting the content any way it wants.

NatspecJSONTest interprets it as Natspec JSON. It does it inside parseCustomExpectations(), which is virtual and provided specifically so that the derived class can put such a logic there. We it could do this already in constructor, like CommonSyntaxTest does, though I don't really like that mechanism - it's too implicit and I feel like it would be too easy to mess up the order.

I could have used any other separator, but reusing this one seemed logical. The only downside is that we have two when the error section is empty. On the other hand, I don't have to worry about inventing a new one and making sure it's not used for something else.

Comment on lines +26 to +28
// "kind": "user",
// "methods": {},
// "version": 1
Copy link
Member Author

@cameel cameel Aug 21, 2023

Choose a reason for hiding this comment

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

By the way, we could filter out kind and version to make the expectations a little shorter. Should we? version is the same for all tests and kind is redundant.

The original tests were inconsistent about it. Some had these fields, but many did not, because the Boost test case allowed omitting them. The downside was that they were not checked, even if included - I actually find one or two places where we were expecting the wrong value. Checking them does not add all that much value though.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd keep them.

@cameel cameel force-pushed the syntax-test-more-extension-points branch from 80511e8 to f4146ee Compare August 21, 2023 15:08
@cameel cameel force-pushed the extracted-natspec-json-tests branch 2 times, most recently from a8cd268 to a6e703b Compare August 22, 2023 13:45
@cameel cameel force-pushed the syntax-test-more-extension-points branch from 5fa0993 to bf0d51d Compare August 22, 2023 13:45
@cameel cameel force-pushed the extracted-natspec-json-tests branch from a6e703b to 7fc81d0 Compare August 22, 2023 13:46
@cameel cameel force-pushed the syntax-test-more-extension-points branch from bf0d51d to 7768f26 Compare August 22, 2023 19:17
@cameel cameel force-pushed the extracted-natspec-json-tests branch from 7fc81d0 to ae25418 Compare August 22, 2023 19:19
@cameel cameel force-pushed the syntax-test-more-extension-points branch from 7768f26 to e847596 Compare August 23, 2023 16:00
Base automatically changed from syntax-test-more-extension-points to develop August 23, 2023 16:48
@cameel cameel force-pushed the extracted-natspec-json-tests branch from ae25418 to f29ac54 Compare August 23, 2023 16:51
@cameel cameel marked this pull request as ready for review August 23, 2023 16:52
matheusaaguiar
matheusaaguiar previously approved these changes Aug 23, 2023
Copy link
Collaborator

@matheusaaguiar matheusaaguiar left a comment

Choose a reason for hiding this comment

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

I manually checked that all tests from SolidityNatspecJSON.cpp were transferred.

@cameel cameel force-pushed the extracted-natspec-json-tests branch from 2674048 to 9ed96d4 Compare September 7, 2023 12:37
@cameel cameel mentioned this pull request Sep 7, 2023
Copy link
Collaborator

@nikola-matic nikola-matic left a comment

Choose a reason for hiding this comment

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

So, the main portion of the review I've done locally - i.e. playing around with the tests to see whether it's detecting failures properly, and indeed it does.

The comments I left are really more out of curiosity than anything else. I think it's perfectly fine to merge this as soon as the osx jobs are fixed, i.e. no point in waiting much further.

Comment on lines +39 to +40
case NatspecJSONKind::Devdoc: _output << "devdoc"; break;
case NatspecJSONKind::Userdoc: _output << "userdoc"; break;
Copy link
Collaborator

Choose a reason for hiding this comment

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

You don't indent cases inside a switch statement? Is that our style?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. I actually don't like that style too much (I'd prefer the cases to be indented one level), but I stick to it because that's the style used around the code base.

// sometimes uint and they compare as different even when both are 1.
return
SyntaxTest::expectationsMatch() &&
prettyPrinted(obtainedNatspec()) == prettyPrinted(m_expectedNatspecJSON);
Copy link
Collaborator

Choose a reason for hiding this comment

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

obtainedNatspec() returns both devdoc and userdoc for requested contracts, and many tests only expect either userdoc or devdoc; how does this comparison work?

Copy link
Member Author

Choose a reason for hiding this comment

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

many tests only expect either userdoc or devdoc

It used to be the case in the boost tests but if you look at the new expectations, they now always have both userdoc and devdoc.

See commit e702640 (natspecJSON: Generate missing expectations (including errors)), which adds those expectations (auto-generated by isoltest).

output += "\n\n";
first = false;

output += contractName + " " + toString(jsonKind) + "\n";
Copy link
Collaborator

Choose a reason for hiding this comment

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

Multisource tests also include the file name, e.g. Testfile.sol:Token devdoc, so where does said filename and : delimiter come from? Is it inherited from SyntaxTest?

Copy link
Member Author

@cameel cameel Sep 8, 2023

Choose a reason for hiding this comment

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

That's the fully-qualified contract name. It comes from compiler().contractNames() and it's what all of its functions expect when the parameter is a contract name. That's how CompilerStack refers to contracts.

@nikola-matic nikola-matic removed the has dependencies The PR depends on other PRs that must be merged first label Sep 8, 2023
…nversion

- Expectation order matching the order of contracts in the source
- Typos in test names
- Redundant prefixes in test names
- Wrong 'king' in some expectations (it's not checked by the test suite)
…ot be handled correctly by the script

- dev_multiple_params_mixed_whitespace has whitespace that is not completely preserved
- dev_explicit_inherit_complex is a multi-file test
@cameel cameel merged commit 64a0f62 into develop Sep 11, 2023
1 check passed
@cameel cameel deleted the extracted-natspec-json-tests branch September 11, 2023 17:28
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.

Testing Natspec JSON via isoltest
3 participants