Errors should be "click on-able"

[PatrickAlphaC]

Putting them in a temp folder makes it difficult to view them in my text editor.

[s3bc40]

I have a proposal for a solution in there: #196

I struggled a little to find a way to avoid any duplicated code, to be able to act at one point only. But the only way that gave me some results is from my PR: by passing the original path from a fixture and apply a utility helper to remap the path from the tracebacks.

I did it for the cli deployments script, but if it is an accepted solution, I can do the others. (I'll try to do them later)

Also, not really satisfied by the fact that it can duplicate the console output (one with the original and the temp), since traceback is immutable, apparently.

---

EDIT:

I reworked what I did so... Let's see if it fits the requirements!

[PatrickAlphaC]

Thanks for working on this!

It looks like there is actually a lot of good stuff we can use in this PR! Some nice reworking of these tests - they were pretty messy and this is a nice clean up.

I'm struggling to see how this fixing the issue though? I'm a bit upset I didn't give enough direction on this :(

What the issue is trying to solve, is that when you run something like:

mox compile

And you get an error, the error is "clickable" meaning you can CMD + Click the line in the error which will bring you to the line in the contract that has the issue.

What do you think? I feel like we should merge in your refactor where you clean up the architecture, but keep the issue open with more details?

[s3bc40]

Yeah my bad on this, I jumped into my assumptions that it was related to tempfile.TemporaryDirectory() inside the test suite. I should have asked first, even though I managed to understand what could be the issue, and maybe we should just catch the specific error and apply the restore_original_path_in_error in mox compile

We can add what I have done as a refacto, but I think I'll remove the restore_original_path_in_error from the tests.utils since it might be overkilled with pytest wrapping all the error and log output.

I'll try to add restore_original_path_in_error logic in the right solution for this issue if I pin down the moment I can catch the error.

---

I think I'll close this PR #196 and cleanup the commit history from the wip and reworks. It will be nicer to arrange this in one clean commit. Also renaming the branch will be better I think...

Then I will come up with a solution for this issue specifically! 👍

• Rework tests -> Rework - Move conftest const in their file and adapt import in test files #197
• PR for the issue

[s3bc40]

On my Linux, I still have the clear path of the error after mox compile. When I Ctrl + Click on this error from vscode, for example:

vyper.exceptions.StructureException: Expressions without assignment are disallowed

  (hint: did you mean to assign the result to a variable?)

  contract "/home/<PATH>/my_project/src/Counter.vy:9", function "set_number", line 9:4 
       8     self.number = new_number
  ---> 9     hello
  -----------^
      10

It opens the right file, but maybe there is a specific way to trigger this... 🤔

[PatrickAlphaC]

When you CTRL + Click this line /home/<PATH>/my_project/src/Counter.vy ? It opens to the correct file?

[s3bc40]

Yes, I can get the exact path of the file and when CTRL+Click it opens the file:

vyper.exceptions.StructureException: Expressions without assignment are disallowed

  (hint: did you mean to assign the result to a variable?)

  contract "<MY_HOME_PATH>/mox-cu/mox-fav-cu/src/favorites.vy:32", function "store", line 32:4 
       31     self.my_favorite_number = favorite_number
  ---> 32     Bad
  ------------^
       33     # log Transfer()

---

But it depends on the error, I tried yours from your screenshot with a log Transfer() without any args:

event Transfer:
    sender: indexed(address)
    to: indexed(address)
    value: uint256

@external
def store(favorite_number: uint256):
    self.my_favorite_number = favorite_number
    # Bad
    log Transfer()

vyper.exceptions.ArgumentException: Invalid argument count for call to 'Transfer': expected 3, got 0

  contract "<MY_HOME_PATH>/mox-cu/mox-fav-cu/src/favorites.vy:33", function "store", line 33:8 
       32     # Bad
  ---> 33     log Transfer()
  ----------------^
       34

It opens on the exact line, but with a syntax exception:

event Transfer:
    from: indexed(address) #--> here is the error
    to: indexed(address)
    value: uint256

vyper.exceptions.SyntaxException: invalid syntax (<unknown>, line 19)

  line 19:9 
       18 event Transfer:
  ---> 19     from: indexed(address)
  -----------------^
       20     to: indexed(address)

I do not have the path. But I always have the traceback from my home folder, not from the Linux tmp folder. I tried to check the differences from Linux and Mac, but I wonder where it could come from... Maybe I am doing something wrong on my side?

## macOS:

**System-Wide Temporary Directories:**

- /tmp (linked to /private/tmp): This directory is accessible system-wide and is typically cleared upon system reboot. Additionally, macOS includes maintenance scripts that periodically clean up this directory. 
-/var/tmp (linked to /private/var/tmp): Unlike /tmp, this directory is intended for temporary files that need to persist across reboots. It is not cleared automatically upon reboot and retains its contents for longer periods. 
APPLE.STACKEXCHANGE.COM

**User-Specific Temporary Directory:**

- $TMPDIR: This environment variable points to a user-specific temporary directory, typically located at /var/folders/.../T/. Files in this directory are usually cleared upon reboot, and macOS may also perform periodic cleanups to remove stale files. 

---

## Linux:

**System-Wide Temporary Directories:**
- /tmp: This directory is used for temporary files needed during system operation. It is often cleared upon system reboot, and some systems may mount /tmp as a tmpfs (RAM-based filesystem), meaning its contents are stored in volatile memory. 
- /var/tmp: This directory is intended for temporary files that should persist across reboots. It is generally not cleared automatically upon reboot and is used for files that need to remain available for a longer duration.

[s3bc40]

More related to the VVM. If we want to address the issue we have to catch a VMM error specifically.

[PatrickAlphaC]

Yeah... Might have to crack into titanoboa