Open jayvdb opened 1 month ago
When I quit, I see
error: proc-macro derive panicked
--> /home/jayvdb/.cargo/registry/src/dl.cloudsmith.io-34658c4fc5e42bfd/<private crate>/src/newtypes.rs:11:37
|
11 | #[derive(.., FieldType, ...)]
| ^^^^^^^^^
|
= help: message: called `Result::unwrap()` on an `Err` value: IO(Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" })
...
error: custom attribute panicked
--> /home/jayvdb/.cargo/registry/src/dl.cloudsmith.io-34658c4fc5e42bfd/<private crate>/src/lib.rs:78:5
|
78 | #[model]
| ^^^^^^^^
|
= help: message: called `Result::unwrap()` on an `Err` value: IO(Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" })
This crate is intentionally writing to the filesystem. fwiw, FieldType
and model
cant be seen in https://github.com/Electron100/butane
Seems like sandboxing might have caused the problem.
Thanks. I'll have a look at the behaviour when a proc macro gets a sandbox violation and make sure it's not doing anything it shouldn't.
Proc macros are sandboxed by virtue of all of rustc being sandboxed - so unlike build scripts, there's no per-crate sandbox config for proc macros. You can however adjust or disable the sandbox for rustc. e.g.
[rustc.sandbox]
make_writable = [
"/some/path"
]
Or disable it completely
[rustc.sandbox]
kind = "Disable"
This workaround let me get past this issue
[rustc.sandbox]
kind = "Disabled"
Is there a way to use make_writable
with a relative path? so I dont need to do explicit /home/jayvdb/.cargo/registry/src/
?
Is there a way to use
make_writable
with a relative path? so I dont need to do explicit/home/jayvdb/.cargo/registry/src/
?
Yep, if you give it a path that's not absolute, it should be interpreted as relative to the workspace root
I suspect this one might be writing to the source in /home/jayvdb/.cargo/registry/src/
. I'll need to investigate, and I can probably make it stop writing there. So consider this specific case solved on my side.
So I guess this task should be just about how to show the user that there was a compilation problem when they are in the "full" ui mode.
Odd that it got stuck. I just tried writing to a file from a proc macro and running it through cargo acl
and when it hits the error, it exits the TUI and prints the error.
❯ cargo acl
Compiling pmacro1 v0.1.0 (/home/david/work/experiments/example-proc-macro/pmacro1)
Compiling hello_world v0.1.0 (/home/david/work/experiments/example-proc-macro/hello_world)
error: proc macro panicked
--> hello_world/src/main.rs:3:1
|
3 | make_answer!();
| ^^^^^^^^^^^^^^
|
= help: message: called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }
error[E0425]: cannot find function `answer` in this scope
--> hello_world/src/main.rs:6:28
|
6 | println!("Answer: {}", answer());
| ^^^^^^ not found in this scope
For more information about this error, try `rustc --explain E0425`.
error: could not compile `hello_world` (bin "hello_world") due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: could not compile `hello_world` (bin "hello_world" test) due to 2 previous errors
Error: `cargo` exited with non-zero exit status
I think it waits for any other compilation that's running in parallel to finish though - so perhaps there was still other stuff building?
I am guessing that this is now at the step of doing a build of my project, rather than building the deps.My process list
My project typically takes ~30mins to build, and I am building using Bubblewrap sandbox, so that may make it slower.
Some visual indication of what is going on would be helpful.
It is a mono-repo with a lot of members. Perhaps add ability to build each of them separately, and indicate which ones is being built - this would be slower, but at least the user can see progress.