TUI stuck showing "Build in progress..." when there is a build failure

[jayvdb]

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

3029927 pts/2    Sl+    0:32  |       |   \_ /home/jayvdb/.cargo/bin/cargo-acl acl
3029972 pts/2    Sl+    0:01  |       |       \_ /home/jayvdb/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo --color=always build --config profile.cackle.

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.

[jayvdb]

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.

[davidlattimore]

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"

[jayvdb]

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/ ?

[davidlattimore]

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

[jayvdb]

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.

[davidlattimore]

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?