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

Allow specifying a file when running from stdin to use in place of stdinfile.nim #24569

Open
ire4ever1190 opened this issue Dec 26, 2024 · 1 comment

Comments

@ire4ever1190
Copy link
Contributor

Summary

Have a CLI switch like --actualfile which specifies the file that the input represents. Then all error messages and resolving config files will use that file path instead

Description

For tooling based on nim check its easier to store the file in memory and pass it via stdin. This has a few limitations

  • Error messages report as being from stdinfile.nim and so need to be converted before being shown to the user
  • Config files that are $file.nims are not loaded
  • currentSourcePath() returns stdinfile.nim so checking code that uses files relative to the source file always fails

The flag should make the compiler treat the input as coming from an actual file and use that when referencing to errors inside the input and resolving other files like configs

Alternatives

The Nim compiler API could be used instead but this has the problems of

  • Not being able to cancel checking as easily as just killing a process
  • Tooling is then linked to the version of Nim that it was built with, user then has to recompile every Nim update

Also could use nimsuggest which supports a dirtyfile flag, but issues like #24413 make it a pain

Examples

echo "something()" | nim check --actualfile:foo.nim -

/the/current/working/directory/foo.nim(1, 1) Error: undeclared identifier: 'something'

echo "something()" | nim check --actualfile:/absolute.nim -

/absolute.nim(1, 1) Error: undeclared identifier: 'something'

Backwards Compatibility

Shouldn't cause any problems

Links

No response

@Araq
Copy link
Member

Araq commented Dec 26, 2024

Meh, at least this solution is better than dirtyflag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants