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

Move collector to librustc_mir::monomorphize #45525

Merged
merged 26 commits into from
Dec 19, 2017
Merged

Conversation

MaikKlein
Copy link
Contributor

cc #44334 and #45276

  • I moved the collector to rustc_mir

  • I renamed TransItem to MonoItem. (I still need to fix up comments and variable names)

  • I got rid of common.rs and monomorphize.rs from librustc_trans_utils. I moved most of the functionality into TyCtxt. I realized that the librustc_trans_utils::common.rs was just copy pasted from librustc_trans::common.rs.

Should I also get rid of the librustc_trans::common.rs in this PR? Most of the functionality seems a bit useless, I decided to put some of it into TyCtxt but maybe that is not the correct action here.

Should I also get rid of librustc_trans_utils completely here? Or should I do it in a separate PR?

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 25, 2017
@eddyb
Copy link
Member

eddyb commented Oct 25, 2017

r? @eddyb

@@ -45,6 +45,51 @@ pub enum InstanceDef<'tcx> {
CloneShim(DefId, Ty<'tcx>),
}

impl<'a, 'tcx> TyCtxt<'a, 'tcx, 'tcx> {
pub fn is_inline_instance(
Copy link
Member

Choose a reason for hiding this comment

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

Where is this used? In general, I'd expect these methods to be on Instance, or where possible, InstanceDef, and private if only used locally. (I was trying to come up with better name for them)

Copy link
Contributor Author

@MaikKlein MaikKlein Oct 26, 2017

Choose a reason for hiding this comment

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

This is only used in requests_inline afaik. But the original function is used in callee.rs and trans_item_rs. I can move it to instance, I wasn't sure where to put it because it takes an instance and a tyctxt.

}
}

pub fn requests_inline(
Copy link
Member

Choose a reason for hiding this comment

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

I think this should be called requires_local_instance or something else along those lines.

@@ -2380,6 +2380,21 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> {
}
}

impl<'a, 'tcx> TyCtxt<'a, 'tcx, 'tcx> {
pub fn is_sized(self, ty: Ty<'tcx>) -> bool {
Copy link
Member

Choose a reason for hiding this comment

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

Ideally these two methods would be avoided. I wonder what the DUMMY_SP is used for - is_sized should never cause an ICE or an user error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wasn't sure about those functions, there are still a bunch of them in rustc_trans::common.rs. Initially I thought I would move them into TyCtxt but then I asked myself if they should even exist. Should I remove them?

Copy link
Member

Choose a reason for hiding this comment

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

Depends on what the usage looks like.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I haven't investigated it so far. These functions were just copied (not moved) into trans_utils::common.rs and therefore are only used in the collector IIRC. But the original functions are probably more widespread.

Copy link
Member

Choose a reason for hiding this comment

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

Replacing the uses in the collector with the more common forms is probably the best first step.

//!
//!
//! General Algorithm
//! - Methm
Copy link
Member

Choose a reason for hiding this comment

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

This looks to be accidentally truncated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure what happened, I am fixing it now.

@@ -27,6 +27,7 @@ rustc_incremental = { path = "../librustc_incremental" }
rustc_llvm = { path = "../librustc_llvm" }
rustc_platform_intrinsics = { path = "../librustc_platform_intrinsics" }
rustc_trans_utils = { path = "../librustc_trans_utils" }
Copy link
Member

Choose a reason for hiding this comment

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

What's left of rustc_trans_utils?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Oh I think you can throw them into librustc/middle if you want to move them. But nothing I see there should retain its current form anyway.

) -> bool {
use hir::map::DefPathData;
let def_id = match instance.def {
let def_id = match self.def {
Copy link
Member

Choose a reason for hiding this comment

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

With only self.def being accessed, doesn't this method belong on InstanceDef? Same for requires_local_instance.

Copy link
Contributor Author

@MaikKlein MaikKlein Oct 27, 2017

Choose a reason for hiding this comment

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

You are right, I haven't looked too closely.

@MaikKlein MaikKlein force-pushed the collector branch 3 times, most recently from f8b8e0c to af37af2 Compare October 27, 2017 12:53
@@ -45,6 +45,16 @@ pub enum InstanceDef<'tcx> {
CloneShim(DefId, Ty<'tcx>),
}

impl<'a, 'tcx> Instance<'tcx> {
pub fn instance_ty(&self,
Copy link
Member

Choose a reason for hiding this comment

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

I'd call this ty. One thing I'm worried about is trans_apply_param_substs failing if this is accidentally used somewhere where a ParamEnv is needed or some such.
Shouldn't self.def.def_ty(tcx).subst(tcx, self.substs) suffice?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@eddyb I don't really know the details of substitutions yet. I have updated this function to use self.def.def_ty(tcx).subst(tcx, self.substs) but then I get an ICE in run_cargo (see latest build error). Everything seems to work when I use trans_apply_param_substs.

Should I still avoid trans_apply_param_substs? I can investigate further why it crashes if you want me to.

@@ -2380,6 +2380,17 @@ impl<'a, 'gcx, 'tcx> TyCtxt<'a, 'gcx, 'tcx> {
}
}

impl<'a, 'tcx> TyCtxt<'a, 'tcx, 'tcx> {
/// Given a DefId and some Substs, produces the monomorphic item type.
Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't exist - maybe inline the body or use Instance::new(def_id, substs).ty(tcx) instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh sorry I should have looked closer, I am removing it now.

@bors
Copy link
Contributor

bors commented Oct 28, 2017

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

@MaikKlein MaikKlein force-pushed the collector branch 2 times, most recently from 1bed931 to e0bcb86 Compare October 28, 2017 19:09
@bors
Copy link
Contributor

bors commented Oct 29, 2017

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

@kennytm kennytm 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 Oct 29, 2017
@MaikKlein MaikKlein force-pushed the collector branch 5 times, most recently from ec4b1dd to d13f021 Compare October 29, 2017 22:48
@arielb1
Copy link
Contributor

arielb1 commented Dec 18, 2017

@bors r=eddyb

@bors
Copy link
Contributor

bors commented Dec 18, 2017

📌 Commit effd99f has been approved by eddyb

@arielb1
Copy link
Contributor

arielb1 commented Dec 18, 2017

@bors r=eddyb

@bors
Copy link
Contributor

bors commented Dec 18, 2017

📌 Commit b6a7688 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Dec 18, 2017

⌛ Testing commit b6a768861d44c0c24be3156713cdbe04428406fd with merge b36b12eed2daecdf436755834f9e858141d212eb...

@bors
Copy link
Contributor

bors commented Dec 18, 2017

💔 Test failed - status-travis

@bjorn3
Copy link
Member

bjorn3 commented Dec 18, 2017

[...]
[00:04:28] Command failed. Attempt 5/5:
[00:04:29] Cleared directory 'src/tools/miri'
[00:04:29] Submodule 'src/tools/miri' (https://github.com/solson/miri.git) unregistered for path 'src/tools/miri'
[00:04:29] Submodule 'src/tools/miri' (https://github.com/solson/miri.git) registered for path 'src/tools/miri'
[00:04:29] error: no such remote ref a23e587dc3a55a766ddd95454fd8368988cc7a3a
[00:04:29] Fetched in submodule path 'src/tools/miri', but it did not contain a23e587dc3a55a766ddd95454fd8368988cc7a3a. Direct fetching of that commit failed.
[00:04:29] The command has failed after 5 attempts.
[...]

@eddyb
Copy link
Member

eddyb commented Dec 18, 2017

Need to undo the miri submodule change.

@arielb1
Copy link
Contributor

arielb1 commented Dec 18, 2017

@bors r=eddyb

@bors
Copy link
Contributor

bors commented Dec 18, 2017

📌 Commit 6e78b66 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Dec 18, 2017

⌛ Testing commit 6e78b66 with merge 0a440e76bff84933783d590cf47ee811c5b345a0...

@bors
Copy link
Contributor

bors commented Dec 18, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

kennytm commented Dec 18, 2017

@bors retry #46313.

@bors
Copy link
Contributor

bors commented Dec 18, 2017

⌛ Testing commit 6e78b66 with merge 68e6abacfa269e101e7f6f2e7f83d0527012ae0a...

@bors
Copy link
Contributor

bors commented Dec 19, 2017

💔 Test failed - status-appveyor

@bors
Copy link
Contributor

bors commented Dec 19, 2017

⌛ Testing commit 6e78b66 with merge b76f224...

bors added a commit that referenced this pull request Dec 19, 2017
Move collector to librustc_mir::monomorphize

cc #44334 and #45276

* I moved the collector to rustc_mir

*  I renamed `TransItem` to `MonoItem`. _(I still need to fix up comments and variable names)_

* I got rid of `common.rs` and `monomorphize.rs` from `librustc_trans_utils`. I moved most of the functionality into `TyCtxt`. I realized that the `librustc_trans_utils::common.rs` was just copy pasted from `librustc_trans::common.rs`.

Should I also get rid of the `librustc_trans::common.rs` in this PR? Most of the functionality seems a bit useless, I decided to put some of it into `TyCtxt` but maybe that is not the correct action here.

Should I also get rid of `librustc_trans_utils` completely here? Or should I do it in a separate PR?
@bors
Copy link
Contributor

bors commented Dec 19, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing b76f224 to master...

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.