-
Notifications
You must be signed in to change notification settings - Fork 1.8k
internal: Fix lockfile temp dir usage and use it for build scripts as well #20315
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
Conversation
crates/base-db/src/input.rs
Outdated
ProcMacroLoadingError::MissingDylibPath(candidates) => { | ||
write!( | ||
f, | ||
"proc-macro crate built but the dylib path is missing, this indicates a problem with your build system. Candidates not considered: {}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Candidates considered or not considered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not considered, these are files got from rustc/cargo that do not have a dylib extension for the platform. See
rust-analyzer/crates/project-model/src/build_dependencies.rs
Lines 490 to 496 in 7a62181
// FIXME: Find a better way to know if it is a dylib. | |
fn is_dylib(path: &Utf8Path) -> bool { | |
match path.extension().map(|e| e.to_owned().to_lowercase()) { | |
None => false, | |
Some(ext) => matches!(ext.as_str(), "dll" | "dylib" | "so"), | |
} | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjusted the message to make that more clear
bc7fdae
to
3b6aeeb
Compare
Oh haha, I think I now know the issue with the dylib not being found sometimes. The package versions reported by cargo metadata and our build script command sometimes go out of sync because we aren't locking the lockfile I believe |
Nevermind, that's not the issue. |
ad1374b
to
ce66520
Compare
ce66520
to
df85aac
Compare
So I think what #18508 observes is that our metadata fetching and build script building may disagree on the exact package ids due to differing lockfiles. I believe this PR should fix that but I am not 100% sure |
Going to merge this now before our release tomorrow as we otherwise pollute the temp dirs too much and b) compile time deps easily breaking from that |
Groan something broke in here silently |
Oops, my bad 😅
FWIW I guess it doesn't because the implementation only affects whether to enqueue a unit compilation job into the job queue or not and it happens after the dependency resolution |
cc #18508
Didn't notice that in #20290 but it drops the temp dir before the metadata call gets invoked, meaning we never run it against a lockfile