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

build.rs probe fails to propagate --target and does not use RUSTC_WRAPPER #84

Closed
RalfJung opened this issue Aug 5, 2022 · 10 comments · Fixed by #160
Closed

build.rs probe fails to propagate --target and does not use RUSTC_WRAPPER #84

RalfJung opened this issue Aug 5, 2022 · 10 comments · Fixed by #160
Assignees
Labels
A-eyre Area: eyre subcrate C-bug Category: Something isn't working P-important (Priority) something that contributes towards achieving the long term goals of the project

Comments

@RalfJung
Copy link

RalfJung commented Aug 5, 2022

In tricky build situations, such as when bootstrapping rustc or for cross-compilation, it is crucial to set the right --target argument for rustc invocations. The build.rs script of eyre doesn't do that, and I think that's why I am now getting build failures in eyre inside a rustc bootstrap situation:

error[E0407]: method `backtrace` is not a member of trait `StdError`
   --> /home/r/.cargo/registry/src/github.com-1ecc6299db9ec823/eyre-0.6.8/src/context.rs:147:5
    |
147 | /     fn backtrace(&self) -> Option<&Backtrace> {
148 | |         self.error.backtrace()
149 | |     }
    | |_____^ not a member of trait `StdError`

Basically, I think eyre needs the same patch as dtolnay/anyhow#249.
(FWIW autocfg gets all this right, but it seems a lot of crates re-implement the autocfg logic -- incorrectly.)

@RalfJung
Copy link
Author

RalfJung commented Aug 5, 2022

There are also other issues with this build probe:

  • it doesn't propagate CARGO_ENCODED_RUSTFLAGS, and hence will fail when -Zallow-features is used.
  • it doesn't respect RUSTC_WRAPPER, though I am not sure if that actually causes trouble (the wrapper could add -Zallow-features, I guess, or switch to a totally different compiler).

@RalfJung
Copy link
Author

RalfJung commented Aug 8, 2022

Due to rust-lang/rust-analyzer#12973 I would currently advise against honoring RUSTC_WRAPPER.

@thenorili thenorili self-assigned this Nov 20, 2023
@thenorili
Copy link
Contributor

I'll fold this into my active work on the compile probe, thanks for the concern!

@RalfJung
Copy link
Author

Note that rust-lang/rust-analyzer#12973 has been fixed by now. The anyhow probe is probably a good template to follow.

@thenorili
Copy link
Contributor

I'm already copying over their probe in the pr where i get backtrace working again : )

@RalfJung
Copy link
Author

RalfJung commented Mar 26, 2024

eyre not honoring RUSTC_WRAPPER is now blocking improvements in Miri (rust-lang/miri#3411). Miri would really like to rely on all rustc invocations going through the wrapper, it is very hard to support build scripts that bypass this. (We currently have some hacks to make that work but it's not holding together well.)

Writing build probes is not easy, there are a lot of flags and corner cases one has to worry about. It is easy to get the "general" case to work, but making it work in more exotic circumstances (e.g. when interpreting a crate using Miri for a different target) is tricky. Unfortunately everyone hand-rolls their own build probe logic so people caring about those more exotic circumstances have to file countless PRs and issues to fix the same oversights over and over again, which is tiring.

autocfg has a very well-tested build probe logic, and provides a single place to fix issues for exotic configurations, should they arise. @thenorili I wonder if you would be open to taking autocfg as a dependency, if cuviper/autocfg#24 would get resolved and you could access its build probe logic? @cuviper would you be willing to expose support for custom probes from autocfg, given a clear usecase like this one?

@ten3roberts
Copy link
Contributor

Thank you for bringing this to attention.

We debated last week about trying autocfg, as I've used it before with success.

I'll see if I can push out a branch that uses autocfg for nightly backtraces etc

@ten3roberts
Copy link
Contributor

ten3roberts commented Mar 26, 2024

Regarding the open issues you mentioned on autocfg, as well as cuviper/autocfg#43 we are not able to detect using just autocfg if we have backtraces or nightly available.

My idea is to use RUSTCFLAGS and add a eyre-unstable-backtrace etc for the nightly features, similarly to how wgpu does with with WebGPU using web-sys https://rustwasm.github.io/wasm-bindgen/web-sys/unstable-apis.html

@ten3roberts ten3roberts self-assigned this Mar 26, 2024
@ten3roberts ten3roberts added C-bug Category: Something isn't working P-important (Priority) something that contributes towards achieving the long term goals of the project A-eyre Area: eyre subcrate labels Mar 26, 2024
@RalfJung
Copy link
Author

Regarding the open issues, as well as cuviper/autocfg#43 we are not able to detect using just autocfg if we have backtraces or nightly available.

That's why I mentioned cuviper/autocfg#24. autocfg could expose its underlying build probe functionality to let you write an arbitrary piece of Rust code that will then be tested for whether it compiles.

ten3roberts added a commit that referenced this issue Mar 26, 2024
This addresses the invalid compile probe testing for a non-longer
existing feature by updating it and eyre to use the
`error_generic_member_access` features instead.

The report and errors have all been updated to accomodate this and the
new backtrace provide API

Fixes: #84 and #97
ten3roberts added a commit that referenced this issue Mar 26, 2024
This addresses the invalid compile probe testing for a non-longer
existing feature by updating it and eyre to use the
`error_generic_member_access` features instead.

The report and errors have all been updated to accomodate this and the
new backtrace provide API

Fixes: #84 and #97
ten3roberts added a commit that referenced this issue Mar 26, 2024
This addresses the invalid compile probe testing for a non-longer
existing feature by updating it and eyre to use the
`error_generic_member_access` features instead.

The report and errors have all been updated to accomodate this and the
new backtrace provide API

Fixes: #84 and #97
ten3roberts added a commit that referenced this issue Mar 26, 2024
This addresses the invalid compile probe testing for a non-longer
existing feature by updating it and eyre to use the
`error_generic_member_access` features instead.

The report and errors have all been updated to accomodate this and the
new backtrace provide API

Fixes: #84 and #97
ten3roberts added a commit that referenced this issue Mar 26, 2024
This addresses the invalid compile probe testing for a non-longer
existing feature by updating it and eyre to use the
`error_generic_member_access` features instead.

The report and errors have all been updated to accomodate this and the
new backtrace provide API

Fixes: #84 and #97
@RalfJung RalfJung changed the title build.rs probe fails to propagate --target build.rs probe fails to propagate --target and does not use RUSTC_WRAPPER Mar 26, 2024
@cuviper
Copy link

cuviper commented Mar 29, 2024

Regarding the open issues, as well as cuviper/autocfg#43 we are not able to detect using just autocfg if we have backtraces or nightly available.

That's why I mentioned cuviper/autocfg#24. autocfg could expose its underlying build probe functionality to let you write an arbitrary piece of Rust code that will then be tested for whether it compiles.

I have cuviper/autocfg#59 up for that -- please let me know if that will work for you!

ten3roberts added a commit that referenced this issue Jul 18, 2024
This addresses the invalid compile probe testing for a non-longer
existing feature by updating it and eyre to use the
`error_generic_member_access` features instead.

The report and errors have all been updated to accomodate this and the
new backtrace provide API

Fixes: #84 and #97
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-eyre Area: eyre subcrate C-bug Category: Something isn't working P-important (Priority) something that contributes towards achieving the long term goals of the project
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants