Calculate privacy access only via query#57343
Merged
bors merged 2 commits intorust-lang:masterfrom Jan 5, 2019
Merged
Conversation
rust-highfive
added
the
S-waiting-on-review
Contributor
|
@bors r+ Regarding making name resolution results into a query, I think that's definitely feasible but it's going to require some thought to try and do name resolution at anything other than the crate granularity. This conversion is a big part of what we often call "end-to-end queries" (along with parsing). Still, even converting it into a "crate-wide phase" would be awesome. |
Collaborator
|
📌 Commit 480d0f3 has been approved by |
bors
added
S-waiting-on-bors
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Jan 5, 2019
…komatsakis Calculate privacy access only via query Initially converted to query in rust-lang@a9f6bab and then changed to respect dependencies rust-lang@8281e88. I did this as an effort to prune `CrateAnalysis` from librustc_save_analysis, with the only thing remaining being the glob map (`name` is unused, existing `crate_name` is exposed in the compiler passes, instead). Since calculating the glob map is opt-in, it'd be great if we could calculate that on-demand. However, it seems that it'd require converting resolution to queries, which I'm not sure how to do yet. In an effort to get rid of `CrateAnalysis` altogether, could we try unconditionally calculating the glob_map in the resolver, thus completely removing `CrateAnalysis` struct, and doing a perf run? r? @nikomatsakis cc @petrochenkov do you have any idea how/if at all could we querify the resolver? I've stumbled upon a comment that's ~3? years old at the moment, so I'm guessing things might have changed and it actually may be feasible now. https://github.com/rust-lang/rust/blob/fe0c10019d7ee96909cc42cc265ef999a6b5dd70/src/librustc_driver/driver.rs#L589-L593
bors
added a commit
that referenced
this pull request
Jan 5, 2019
Rollup of 17 pull requests Successful merges: - #57219 (Remove some unused code) - #57229 (Fix #56806 by using `delay_span_bug` in object safety layout sanity checks) - #57233 (Rename and fix nolink-with-link-args test) - #57238 (Fix backtraces for inlined functions on Windows) - #57249 (Fix broken links to second edition TRPL.) - #57267 (src/jemalloc is gone, remove its mention from COPYRIGHT) - #57273 (Update the stdsimd submodule) - #57278 (Add Clippy to config.toml.example) - #57295 (Fix 'be be' constructs) - #57311 (VaList::copy should not require a mutable ref) - #57312 (`const fn` is no longer coming soon (const keyword docs)) - #57313 (Improve Box<T> -> Pin<Box<T>> conversion) - #57314 (Fix repeated word typos) - #57326 (Doc rewording, use the same name `writer`) - #57338 (rustdoc: force binary filename for compiled doctests) - #57342 (librustc_mir: Make qualify_min_const_fn module public) - #57343 (Calculate privacy access only via query) Failed merges: - #57340 (Use correct tracking issue for c_variadic) r? @ghost
32 tasks
emilyalbini
added a commit
to emilyalbini/rust
that referenced
this pull request
Jan 12, 2019
…x, r=nikomatsakis save-analysis: use a fallback when access levels couldn't be computed Fixing an RLS regression I introduced in rust-lang#57343 😢 I missed a case where we get [called back with analysis when type checking fails](https://github.com/rust-lang/rust/blob/9d54812829e9d92dac35a4a0f358cdc5a2475371/src/librustc_driver/driver.rs#L1264). Since privacy checking normally is done afterwards, when we execute the `privacy_access_levels` query inside the save_analysis callback we'll calculate it for the first time and since typeck info isn't complete, we'll crash there. Double-checked locally and it seems to have fixed the problem. r? @nikomatsakis
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jan 13, 2019
…x, r=nikomatsakis save-analysis: use a fallback when access levels couldn't be computed Fixing an RLS regression I introduced in rust-lang#57343 😢 I missed a case where we get [called back with analysis when type checking fails](https://github.com/rust-lang/rust/blob/9d54812829e9d92dac35a4a0f358cdc5a2475371/src/librustc_driver/driver.rs#L1264). Since privacy checking normally is done afterwards, when we execute the `privacy_access_levels` query inside the save_analysis callback we'll calculate it for the first time and since typeck info isn't complete, we'll crash there. Double-checked locally and it seems to have fixed the problem. r? @nikomatsakis
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Initially converted to query in a9f6bab and then changed to respect dependencies 8281e88.
I did this as an effort to prune
CrateAnalysisfrom librustc_save_analysis, with the only thing remaining being the glob map (nameis unused, existingcrate_nameis exposed in the compiler passes, instead).Since calculating the glob map is opt-in, it'd be great if we could calculate that on-demand. However, it seems that it'd require converting resolution to queries, which I'm not sure how to do yet.
In an effort to get rid of
CrateAnalysisaltogether, could we try unconditionally calculating the glob_map in the resolver, thus completely removingCrateAnalysisstruct, and doing a perf run?r? @nikomatsakis
cc @petrochenkov do you have any idea how/if at all could we querify the resolver? I've stumbled upon a comment that's ~3? years old at the moment, so I'm guessing things might have changed and it actually may be feasible now.
rust/src/librustc_driver/driver.rs
Lines 589 to 593 in fe0c100