Add CompileMode to Executor callbacks #5830
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This helps distinguish whether a given rustc invocation corresponds to a regular compilation or is it compiled as a test harness. The difference is important for tools like RLS, since checking test code is different than checking what is it regularly compiled as.
|
@bors r+ BTW, we have a |
|
📌 Commit 90a5ba3 has been approved by |
bors
added a commit
that referenced
this pull request
Jul 29, 2018
Add CompileMode to Executor callbacks This came up when trying to fix rust-lang/rls#876. So currently in the RLS we recreate our own dep graph, where we store units with a key `(PackageId, TargetKind)`. This turned out to be not enough since a) we can have multiple bin target kinds with different names (unrelated to this PR) b) same package target kind (bin, lib) can be compiled regularly or including the test harness. With this, we can distinguish these cases and properly rerun both regular compilation check and the one including unit tests. Without this information we'd need to fall back on guessing whether the rustc invocation has `--test` but having this information makes it accurate and seems useful enough to add it to the callback arguments. r? @alexcrichton or @matklad
|
Correct link: #5301 |
|
@matklad yep, saw that one, thanks! In this particular case I'd prefer to use the Cargo API directly, since we're doing it and running it in-process already, however it'd definitely be good to improve the build plan further for the upcoming build system interop work! |
|
☀️ Test successful - status-appveyor, status-travis |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This came up when trying to fix rust-lang/rls#876.
So currently in the RLS we recreate our own dep graph, where we store units with a key
(PackageId, TargetKind). This turned out to be not enough sincea) we can have multiple bin target kinds with different names (unrelated to this PR)
b) same package target kind (bin, lib) can be compiled regularly or including the test harness.
With this, we can distinguish these cases and properly rerun both regular compilation check and the one including unit tests.
Without this information we'd need to fall back on guessing whether the rustc invocation has
--testbut having this information makes it accurate and seems useful enough to add it to the callback arguments.r? @alexcrichton or @matklad