Skip to content
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

Future-proof MIR for dedicated debuginfo. #56278

Merged
merged 9 commits into from
Apr 24, 2019

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Nov 27, 2018

This is #56231 without the last commit (the one that actually moves to VarDebuginfo).
Nothing should be broken, but it should no longer depend on debuginfo for anything else.

r? @nikomatsakis

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 27, 2018
Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these changes look fine, though I'd be happier if we could make some nice queries for getting info about the Nth upvar of a closure, so that the code would be a bit cleaner

@@ -141,6 +142,40 @@ fn do_mir_borrowck<'a, 'gcx, 'tcx>(
.as_local_node_id(def_id)
.expect("do_mir_borrowck: non-local DefId");

// Gather the upvars of a closure, if any.
let upvars: Vec<_> = tcx.with_freevars(id, |freevars| {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This really feels like information that could be encoded in the MIR, no? Well, I guess I can see an argument both ways.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At minimum I would prefer if we can factor it out from borrow check into some kind of helper table that would be more re-usable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I don't know that I want to block the PR on it. In general I feel like the borrow check code is kind of noodly and could use some extractions of this kind.

/// Mark an argument local (which must be a tuple) as getting passed as
/// its individual components at the LLVM level.
///
/// This is used for the "rust-call" ABI.
pub spread_arg: Option<Local>,

/// Names and capture modes of all the closure upvars, assuming
/// the first argument is either the closure or a reference to it.
pub upvar_decls: Vec<UpvarDecl>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw, I think that if there are fields that are "debuginfo" that you feel other people should not rely on, we should comment that =)

(Like this one, judging from previous commit)

PathElem::ClosureVar(Symbol::intern(&field.to_string()))
let mut name = None;
if let Some(node_id) = self.ecx.tcx.hir.as_local_node_id(def_id) {
self.ecx.tcx.with_freevars(node_id, |freevars| {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this has any overlap with the borrow check code I was noting earlier? (i.e., if some common helper could make both of these more concise)

// debuginfo generation, and will be removed at some point.
// Do **NOT** use it for anything else, upvar information should not be
// in the MIR, please rely on local crate HIR or other side-channels.
pub __upvar_debuginfo_codegen_only_do_not_use: Vec<UpvarDebuginfo>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol ok I guess that addresses my earlier concern

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like this to be part of the doc comment please though, why use only //?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got used to only using // for NOTE/FIXME/HACK, but I'll go change it.

@@ -2208,3 +2277,15 @@ impl ContextKind {
}
}
}

#[derive(Debug)]
crate struct Upvar {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think I would prefer to see closure_upvars(def_id, n) -> Upvar that returns this information "nicely collected".... (or closure_upvars(def_id) -> &[Upvar]).

But I won't hold up the PR on it.

r=me, depending on how you feel @eddyb

@nikomatsakis nikomatsakis added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 30, 2018
@bors
Copy link
Contributor

bors commented Dec 2, 2018

☔ The latest upstream changes (presumably #56198) made this pull request unmergeable. Please resolve the merge conflicts.

@XAMPPRocky
Copy link
Member

Triage; @eddyb Hello, have you been able to get back to this PR?

@XAMPPRocky
Copy link
Member

Triage; @eddyb Hello again, have you been able to get back to this PR?

@TimNN
Copy link
Contributor

TimNN commented Jan 22, 2019

Ping from triage @eddyb: What is the status of this PR?

@TimNN TimNN added A-allocators Area: Custom and system allocators and removed A-allocators Area: Custom and system allocators labels Jan 29, 2019
@Dylan-DPC-zz
Copy link

ping from triage @eddyb Unfortunately we haven't heard from you on this in a while, so I'm closing the PR to keep things tidy. Don't worry though, if you'll have time again in the future please reopen this PR, we'll be happy to review it again!

@Dylan-DPC-zz Dylan-DPC-zz added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 4, 2019
@eddyb eddyb reopened this Feb 14, 2019
@eddyb
Copy link
Member Author

eddyb commented Feb 14, 2019

I've started rebasing this, I'll try to get it merged next week.

@eddyb
Copy link
Member Author

eddyb commented Feb 15, 2019

I think I want to get rid of rustc_mir::borrowck::Upvar, I might be able to reuse some of the new information that's in the TypeckTables now.

@bors
Copy link
Contributor

bors commented Feb 22, 2019

☔ The latest upstream changes (presumably #56113) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 22, 2019
@Dylan-DPC-zz Dylan-DPC-zz removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 11, 2019
@TimNN TimNN added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. labels Mar 19, 2019
@Dylan-DPC-zz
Copy link

ping from triage @eddyb any updates? you have conflicts to resolve

@eddyb
Copy link
Member Author

eddyb commented Apr 17, 2019

Regarding #56278 (comment), the TypeckTables field in question is from issue #56905 / PR #56906, i.e.:

// In analyze_closure() in upvar.rs we gathered a list of upvars used by a
// closure and we stored in a map called upvar_list in TypeckTables indexed
// with the closure's DefId. Here, we run through that vec of UpvarIds for
// the given closure and use the necessary information to create UpvarDecl.
let upvar_decls: Vec<_> = hir_tables
.upvar_list
.get(&fn_def_id)
.into_iter()
.flatten()
.map(|upvar_id| {
let var_hir_id = upvar_id.var_path.hir_id;
let var_node_id = tcx_hir.hir_to_node_id(var_hir_id);
let capture = hir_tables.upvar_capture(*upvar_id);

@eddyb
Copy link
Member Author

eddyb commented Apr 23, 2019

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Apr 23, 2019

📌 Commit c3ca9a3 has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 23, 2019
mir.local_decls[*borrowed_local].visibility_scope;

if mir.is_sub_scope(borrowed_local_scope, dropped_local_scope)
if mir.local_decls[*borrowed_local].name.is_some()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why isn't this checking is_user_variable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, looks like is_user_variable is newer than this PR originally, and is actually part of the set of things I meant to review at some point.

Centril added a commit to Centril/rust that referenced this pull request Apr 24, 2019
…tsakis

Future-proof MIR for dedicated debuginfo.

This is rust-lang#56231 without the last commit (the one that actually moves to `VarDebuginfo`).
Nothing should be broken, but it should no longer depend on debuginfo for anything else.

r? @nikomatsakis
@bors
Copy link
Contributor

bors commented Apr 24, 2019

⌛ Testing commit c3ca9a3 with merge d101749a5366c81e052027e957d90b7430566438...

Centril added a commit to Centril/rust that referenced this pull request Apr 24, 2019
…tsakis

Future-proof MIR for dedicated debuginfo.

This is rust-lang#56231 without the last commit (the one that actually moves to `VarDebuginfo`).
Nothing should be broken, but it should no longer depend on debuginfo for anything else.

r? @nikomatsakis
@Centril
Copy link
Contributor

Centril commented Apr 24, 2019

@bors retry

bors added a commit that referenced this pull request Apr 24, 2019
Rollup of 5 pull requests

Successful merges:

 - #56278 (Future-proof MIR for dedicated debuginfo.)
 - #59739 (Stabilize futures_api)
 - #59822 (Fix dark css rule)
 - #60186 (Temporarily accept [i|u][32|size] suffixes on a tuple index and warn)
 - #60190 (Don't generate unnecessary rmeta files.)

Failed merges:

r? @ghost
@bors bors merged commit c3ca9a3 into rust-lang:master Apr 24, 2019
@eddyb eddyb deleted the mir-debuginfo-proof branch April 24, 2019 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants