changes to build scripts and config.toml should always refresh

[BenjaminBrienen]

Discussed here
https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Why.20does.20this.20guard.20exist.3F/with/583780871

Note that this may cause a lot of annoying refreshes when editing build scripts, but this is technically correct.

[Veykril]

Reading this again this change is not correct I think. This will cause us to reload the crate graph entirely when the build script changes which is more work than we should be doing, we should only retrigger build scripts, which we already do on next file save.

The cargo config changes seems correct to me though.

View changes since this review

[BenjaminBrienen]

Is it not possible for a build script to create output that would cause a change in the crate graph? For example, a build script that writes a new workspace member to disk (could be glob included). Maybe the resulting file changes would already trigger the refresh.

[BenjaminBrienen]

Also, why does this logic use ends_with? That doesn't seem like the right way to get the "leaf".

[Veykril]

A buildscript could create a new workspace member yes, but in that case a) I question what you are doing, b) r-a will reload on the creation notification fully (and probably get stuck in a reload loop)

Also, why does this logic use ends_with? That doesn't seem like the right way to get the "leaf".

good question, probably no reason. We should likely use filename there and check that directly

[BenjaminBrienen]

A build script could generate a rest API client crate based on an OpenAPI spec file, for example. If someone adds a line to the build script to generate a second one for another web service, then I wonder if they would have to manually reload the workspace.

[Veykril]

The build script should generate the content of the crate then, not the crate itself. Having build scripts change the crate graph sounds incredibly fishy