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

librustc *still* cannot be used as a library? (trouble resolving libstd) #11063

Closed
killerswan opened this issue Dec 19, 2013 · 2 comments
Closed

Comments

@killerswan
Copy link
Contributor

Moving on from #11026 (where I was missing args[0]), now I'm seeing this at runtime:

$ ./bin/testloop src/demo.rs 
Error in `stat` on `./.tests_in_loop.exe`: std::io::IoError{kind: OtherIoError, desc: "no such file or directory", detail: None}
<<<< building tests >>>>
src/demo.rs:1:0: 1:0 error: can't find crate for `std`
src/demo.rs:1 #[feature(non_ascii_idents)];
              ^
task 'rustc' failed at 'explicit failure', /Users/kevin/code/rust/src/libsyntax/diagnostic.rs:76
task '<main>' failed at 'explicit failure', /Users/kevin/code/rust/src/librustc/lib.rs:398

Where testloop is my program calling rustc::main_args (and trying to build demo.rs)...

cc @alexcrichton

@alexcrichton
Copy link
Member

Closing this as working as intended.

Sadly rustc isn't designed to be the easiest library to use right now, but rustc for better or for worse has a lot of inference based on self_exe_path() of where to find the target libraries to link against (it's tough to find another way). The best fix for this would be to specify the sysroot manually or to also specify an addl_lib_search_path (or something called along those lines). We arguably need better support for finding libraries when using rustc as a library, but for now I don't think that there's much in the way of improving this.

If there are ideas though about how to make guessing where the target libraries are more robust, then that would be fantastic to commit to rustc! For now though, with a lack of ideas, I'm going to close this issue.

@alexcrichton
Copy link
Member

I have opened #11068 as a specific way to go about fixing this issue.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 14, 2023
[`missing_fields_in_debug`]: make sure self type is an adt

Fixes rust-lang#11063, another ICE that can only happen in core.

This lint needs the `DefId` of the implementor to get its fields, but that ICEs if the implementor does not have a `DefId` (as is the case with primitive types, e.g. `impl Debug for bool`), which is where this ICE comes from.

This PR changes the check I added in rust-lang#10897 to be more... robust against `Debug` implementations we don't want to lint.
Instead of just checking if the self type is a type parameter and "special casing" one specific case we don't want to lint, we should probably rather just check that the self type is either a struct, an enum or a union and only then continue.
That prevents weird edge cases like this one that can only happen in core.

Again, I don't know if it's even possible to add a test case for this since one cannot implement `Debug` for primitive types outside of the crate that defined `Debug` (core).
I did make sure that this PR no longer ICEs on `impl<T> Debug for T` and `impl Debug for bool`.
Maybe writing such a test is possible with `#![no_core]` and then re-defining the `Debug` trait or something like that...?

changelog: [`missing_fields_in_debug`]: make sure self type is an adt (fixes an ICE in core)

r? `@Alexendoo` (reviewed the last PRs for this lint)
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 17, 2023
[`missing_fields_in_debug`]: make sure self type is an adt

Fixes rust-lang#11063, another ICE that can only happen in core.

This lint needs the `DefId` of the implementor to get its fields, but that ICEs if the implementor does not have a `DefId` (as is the case with primitive types, e.g. `impl Debug for bool`), which is where this ICE comes from.

This PR changes the check I added in rust-lang#10897 to be more... robust against `Debug` implementations we don't want to lint.
Instead of just checking if the self type is a type parameter and "special casing" one specific case we don't want to lint, we should probably rather just check that the self type is either a struct, an enum or a union and only then continue.
That prevents weird edge cases like this one that can only happen in core.

Again, I don't know if it's even possible to add a test case for this since one cannot implement `Debug` for primitive types outside of the crate that defined `Debug` (core).
I did make sure that this PR no longer ICEs on `impl<T> Debug for T` and `impl Debug for bool`.
Maybe writing such a test is possible with `#![no_core]` and then re-defining the `Debug` trait or something like that...?

changelog: [`missing_fields_in_debug`]: make sure self type is an adt (fixes an ICE in core)

r? `@Alexendoo` (reviewed the last PRs for this lint)
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