When we run `roc run <file>` or `roc <file>` then Roc will compile a
binary and run it. Before this commit we would set the path to the
compiled binary as argv[0]. This commit changes the behavior to make
argv[0] in the binary correspond to the roc file being ran.
This benefits the use of roc scripts that make use of a shebang:
#!/usr/bin/env roc
With this change such scripts will be able to read the path to
themselves out of ARGV. This trick is commonly used for instance by bash
scripts in order to access files relative to the script itself.
This commit alters `roc check` to be able to run on Markdown files. The overall flow is:
- check if the file has a `.md` extension
- if it does extract any fenced code blocks marked as Roc
- write those blocks to temp files
- run `roc check` sequentially on every temp file
- print out the results of `roc check`
- exit early if any individual `roc check` has non-zero exit status
- if the file does not have `.md` extension proceed as before
using `roc_cache_packages_dir()` instead, which will return "~/.cache/roc/packages", which was the existing functionality, but `roc_cache_dir()` will now return "~/.cache/roc"
There are a lot of entry points for a Roc program. They should probably
be all consolidated into one, but for now, when FunctionKind is needed,
determine it from the environment. This fixes EXPERIMENTAL_ROC_ERASE for
`roc test` etc.
Also print the location of a failure when `internal_error!` is called. I
think this should panic instead, and I thought it used to - does anyone
know if that changed?
`writer` is only used by the parent process, so we don't need the
soon-to-be-forked child process to create it just to immediately get
overwritten by `execve`.
`status` isn't the exit code of the program - the actual exit code is
shifted left by 8 bits. We can get that with a `WIFEXITED` check to make
sure the exit code exists, followed by `WEXITSTATUS` to retrieve it.
