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

Switch working dir to test dir in command-line tests #13437

Closed
cameel opened this issue Aug 25, 2022 · 4 comments
Closed

Switch working dir to test dir in command-line tests #13437

cameel opened this issue Aug 25, 2022 · 4 comments
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. 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

@cameel
Copy link
Member

cameel commented Aug 25, 2022

Abstract

Currently, when running command-line tests, the working directory is set to test/cmdlineTests/ and not the directory of the specific test case. This means that we need to repeat the name of the test case (which is often long) to refer to a file inside it.

This is not a big problem as long as we rely on the test runner inserting the file path automatically. There are, however, cases where we do have to spell out the path. For example:

"sources": {
"C": {"urls": ["standard_debug_info_in_yul_and_evm_asm_print_all/in.sol"]}
},

We should be able to do "C": {"urls": ["in.sol"]} instead.

Specification

Adjust cmdlineTests.sh so that it enters test case dir before running it and exits it afterwards. Then remove any hard-coded test case names from test inputs and regenerate expectations.

@cameel cameel added good first issue testing 🔨 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 Aug 25, 2022
@kevin-allen-uf
Copy link

Hi! I'm trying to find a suitable good first contribution and I'd like to help with this issue. Is is claimed by anyone else or can I take it on?

@cameel
Copy link
Member Author

cameel commented Sep 14, 2022

Sure, feel free to take it.

kevin-allen-uf added a commit to kevin-allen-uf/solidity that referenced this issue Oct 3, 2022
@NunoFilipeSantos NunoFilipeSantos added the good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. label Dec 5, 2022
@github-actions
Copy link

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 31, 2023
@github-actions
Copy link

github-actions bot commented Apr 9, 2023

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 Apr 9, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. 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

3 participants