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

isoltest does not support filenames (dots) #9809

Closed
axic opened this issue Sep 15, 2020 · 12 comments
Closed

isoltest does not support filenames (dots) #9809

axic opened this issue Sep 15, 2020 · 12 comments
Labels
build system 🏗️ closed due inactivity The issue/PR was automatically closed due to inactivity. easy difficulty good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. nice to have We don’t see a good reason not to have it but won’t go out of our way to implement it. stale The issue/PR was marked as stale because it has been open for too long. testing 🔨

Comments

@axic
Copy link
Member

axic commented Sep 15, 2020

This seems to be not too intuitive:

$ test/tools/isoltest -t smtCheckerTests/control_flow/revert.sol
Invalid test unit filter - can only contain '[a-zA-Z1-9_/*]*: smtCheckerTests/control_flow/revert.sol

While of course -t smtCheckerTests/control_flow/* or -t smtCheckerTests/control_flow/revert* works.

@aaroosh-07
Copy link

Hi, can I take up this issue. and can you guide me on how to debug this issue

@cameel
Copy link
Member

cameel commented Jul 2, 2021

@aaroosh-07 Sure! Do you have the environment set up and can you run isoltest already? If not, please take a look at these:

Once you have it all set up and want some pointers specific for the task please come over to the #solidity-dev channel and we can discuss it there.

@chriseth
Copy link
Contributor

chriseth commented Jul 5, 2021

What is the actual goal here? -t is used to specify test unit names. It would be nice if also files could be tested directly, but do we really want to use -t for that? Also in that case, should the string be interpreted as a path relative to the current working directory?

@cameel
Copy link
Member

cameel commented Jul 5, 2021

I thought it was to make isoltest work with both
-t smtCheckerTests/control_flow/revert and
-t smtCheckerTests/control_flow/revert.sol.
Currently only the first form works. I can see how this might not make sense in the general case but for our .sol and .yul test cases in standalone files the name of the test always matches the path (just with the extension stripped).

I think that the simplest solution would be to include the extension in test case names when we register them. This would not affect normal boost test cases cases. For the ones in standalone files
-t smtCheckerTests/control_flow/revert would no longer work but both
-t smtCheckerTests/control_flow/revert* and
-t smtCheckerTests/control_flow/revert.sol would.

@cameel
Copy link
Member

cameel commented Jul 5, 2021

By the way, @aaroosh-07 looks like I was too quick with assigning this issue. It's not in the implementation backlog yet which means that we did not really agree on whether we actually want it and in what form. We need to discuss it first.

@aaroosh-07
Copy link

aaroosh-07 commented Jul 6, 2021

okay @cameel.
I think we can make documentation more beginner friendly by adding hard coded relative paths for libevmone.so in Running complier tests\Prerequisite

@cameel
Copy link
Member

cameel commented Jul 6, 2021

@aaroosh-07
@christianparpart has already opened a PR for that yesterday: #11613. If you have any feedback, please join the review :)

Anyway, this issue is blocked for the time being because we need a decision so what do you think about taking a different one? Maybe one of these?

@chriseth
Copy link
Contributor

chriseth commented Jul 7, 2021

I think we should support calling isoltest directly on single files - regardless of where isoltest is called from, i.e. isoltest bla.sol (without -t).

Maybe we can split this into

a) renaming all our file-based tests to include the .sol ending (this should be easy).
b) allowing isoltest to take direct arguments and somehow figure out what kind of test it is (by looking in the containing directory, for example) and then run the test.

@cameel
Copy link
Member

cameel commented Jul 23, 2021

a) sounds good.

With b), which one do you mean (I'd assume option 1 but figure out what kind of test it is suggests something more complex, like in option 2):

  1. Accepting a path to the test relative to the current dir so that instead of

    isoltest --test=syntaxTests/array/concat/bytes_concat_*.sol

    you could do just

    isoltest bytes_concat_*.sol

    as long as you're already inside syntaxTests/array/concat/?

    This sounds like something nice to have, though I'm not sure how useful it would be in practice (for example I rarely cd into test dirs, not sure about other people). It would make it a clear distinction between files and test names though.

  2. Or maybe that

     isoltest bytes_concat_*.sol

    would just figure out where tests matching bytes_concat_*.sol are located and act as if you specified the whole path, regardless of where you are in the filesystem?

    This would be definitely more useful though you can already do something close:

    isoltest --test=*/bytes_concat_*

    With soltest too, but there you have to know exactly how deeply the file is nested:

    soltest --run_test=*/*/*/bytes_concat_*

    You cannot specify the file extension here but doing a) would make it possible.

@cameel
Copy link
Member

cameel commented Aug 4, 2021

We talked about this very briefly on today's call. Basically, this is just a small usability improvement so @chriseth is not too particular about the details.

I'd say, let's do a) and as for b) let's go with option 1, which is in line with a similar change I recently did in cmdlineTests.sh (#11712).

@ekpyron ekpyron added low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. nice to have We don’t see a good reason not to have it but won’t go out of our way to implement it. labels Sep 14, 2022
@cameel cameel added good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. and removed good first issue labels Dec 5, 2022
@github-actions
Copy link

github-actions bot commented Mar 8, 2023

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Mar 8, 2023
@github-actions
Copy link

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

@github-actions github-actions bot added the closed due inactivity The issue/PR was automatically closed due to inactivity. label Mar 16, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build system 🏗️ closed due inactivity The issue/PR was automatically closed due to inactivity. easy difficulty good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. nice to have We don’t see a good reason not to have it but won’t go out of our way to implement it. stale The issue/PR was marked as stale because it has been open for too long. testing 🔨
Projects
None yet
Development

No branches or pull requests

6 participants