`pub use` breaks my compiler

help
1

I don't know how else to say this, but a refactoring I am performing is absolutely breaking my compiler and I have no idea what is going on. Please bear with me, this is weird and frustrating to me and I have no way forward anymore.

What I am doing is I have moved some types from my crate A to another crate B. Literally copy-pasted them. I also added the dependency correctly. So what I am doing to refactor without breaking everything in my crate is to pub use the types in the modules that used them.

Say I had this code in crate A:

pub struct Foo {
 //fields
}

I moved this structure to crate B and changed the code in crate A to:

pub use B::Foo;

I am doing this one by one and this works perfectly fine, except for when I hit a particular struct. I don't think the struct itself is important, but here it goes:

#[derive(Debug, PartialEq, Clone, serde::Serialize, serde::Deserialize)]
pub struct UnivariateLinearRegressionSolution<F: Scalar + Float + ConstOne> {
    pub slope: F,
    pub intercept: F,
    pub jtj_inv: OMatrix<F, U2, U2>,
    pub sample_variance: F,
}

The type OMatrix is a matrix type from nalgebra.

I can still check my code using cargo check, but as soon as I do cargo check --tests, I get hundreds of errors such as

error[E0599]: no method named `len` found for reference `&[F]` in the current scope
    --> rdb-lib\src\regression.rs:171:33
     |
171  |         if independent_variable.len() < 2 {
     |                                 ^^^
     |

(Note that this error is not even in test code. This is non-test code that passes cargo check)

or

error[E0599]: no method named `as_ptr` found for reference `&[f32]` in the current scope
  --> rdb-lib\src\test_util.rs:25:41

There are tons of other failures. It seems it recognizes absolutely no associated functions anymore on any type, mine or foreign.

I've tried:

  • doing this refactor from the beginning (this is my third time)
  • cargo clean
  • uninstalling and installing the Rust toolchain again
  • using a different Rust toolchain (i am currently on 1.81.0)
  • changing operating systems

When I continue with the refactoring it gets so bad that downstream dependencies stop building because the compiler claims it cannot find the alloc module anymore (EDIT: this was caused by something completely unrelated). Please help and thank you.

2 Likes
2

My guess is that you have some cross-compilation target set in Cargo.toml, and that gets ignored for tests because they need to run on the host system. Also make sure you're checking both crates, either by making them default members of the workspace or running cargo check --workspace.

2 Likes
3

Hey, I donā€™t have a cross compile set. Could you elaborate on what you mean by checking both crates? I have deliberately not made them part of the same workspace. What I am doing is including crate B as a dependency in crate Aā€™s cargo.toml. I use the path for now during development. Crate A is indeed part of a workspace, but crate B is not.

4

Then run cargo check (with or without --tests) in both crates separately. Which crates are throwing the errors?

This error happens when core is missing. Usually this just means rustc has failed to link any crates. No idea why this would happen from moving a struct. Maybe you've hit some timeout or disk space limitation.

4 Likes
5

I assume you are running these cargo commands within crate A, and not within your dependency B? Do you get any error messages when you run them inside of B?

Does the first error in the "hundreds of errors" look significant, or is it the same as the rest?

Are you using any special refactoring tools other than the copy-pasting you mentioned?

2 Likes
6

No dependency B on its own compiles fine.

Iā€™ll check the errors again tomorrow.

I am not using special tools.

7

I think youā€™re right that core is missing. Why though? I am stumpedā€¦

8

okay, I had to check today. You're right. I did not see the forest for the trees. There was an impl block for a type that I defined in a test module. That was of course fine in case that type was defined inside my crate and it's forbidden if it's a foreign type. Only that first error was useful, after that it starts with bogus errors like

no method named `iter_mut` found for mutable reference `&'a mut [F]` in the current scope

I'd still be curious why that would have these kinds of catastrophic consequences but this indeed fixed it! Thank you!

1 Like
9

Wild guess: Are you doing the refactor with both crates open in an editor/IDE that might be overzealous about trying to "help you" after you move the definition, even though you manually move it with copy-paste? Maybe vscode with extra extensions, or Rust Rover?

1 Like
10

You did indeed solve my problem and I'll mark your comment as the solution soon. I'll leave the thread open a bit longer to see if anyone has any idea why that happened...

11

that wasn't it, but thank you for taking the time to think about my problem. I'm using helix, which is pretty minimal when it comes to refactoring support...

12

It's a bit of muscle memory I've learned after running into similar situations, I now always make sure to check the first error if the rest confuse me.

Those bogus diagnostics shouldn't be happening in an ideal world though, and your issue is worth reporting in the Rust issue tracker if you can manage to minimize it.

5 Likes
13

A compiler bug resulting in bad additional error messages doesnā€™t seem out of the question.

Perhaps you could try to share a reproducible way to get the error message? If this is an open source project, you can also just share a commit or branch in a state that produces the error and let others do the minimization.

14

Since I now know what triggers it I can try and produce a minimal example. Unfortunately the project itself is not public. Do you think itā€™s worth filing a bug or does this seem normal to you? I mean Iā€™ve seen unhelpful error messages when missing a brace or semicolon but never anything like thisā€¦

15

No this does not seem normal to me, and filing a bug is definitely a great idea (unless perhaps, one can easily find an existing issue describing the same problem). [Also, test it on a current nightly if you havenā€™t already, to rule out any recently-fixed bug.]

5 Likes
16

Looking for existing issues, this might be describing the same thing already

7 Likes
17

Oh dang, yes that seems very relevant. My bonus errors seem a bit more excessive but that might just be because I am working on a bigger example.

18

So whatā€™s happening here is apparently that after the compiler checked the validity of all inherent impl blocks, compilation was made to continue; for some reason though, the compiler is in a state where no inherent impl at all will be found anymore, leading to a potentially huge number of error messages.

3 Likes
19

Thank you for investigating the root cause. It looks like your work breathed new life into the GitHub issue.

2 Likes
20

Indeed, and less than a full day later, and a fix is already being shipped (which should make it into nightly automatically in a day or so[1])

  1. currently, itā€™s still waiting in the queue ā†©ļøŽ

4 Likes