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

[WIP] Move pointee_info_at to TyLayoutMethods. #57150

Open
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@wildarch
Copy link
Contributor

wildarch commented Dec 27, 2018

Resolves #56166.

This moves the pointee_info_at from rustc_codegen_llvm::type_of::LayoutLlvmExt to rustc::ty::layout::TyLayoutMethods.

This pull request is far from ready to be merged, and is only meant for an intermediate review. It will be expanded to a completely resolve #56166.

r? @eddyb

Move pointee_info_at to TyLayoutMethods.
The original implementation is still present at
librustc_codegen_llvm/abi.rs, should be removed later to prevent code
duplication.
@RalfJung

This comment has been minimized.

Copy link
Member

RalfJung commented Dec 27, 2018

Uh I'm sorry don't think I can review this. I don't know this code.

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned RalfJung Dec 27, 2018

@oli-obk
Copy link
Contributor

oli-obk left a comment

Just a preliminary review.

Looks generally alright to me, can you start changing all the previous calls to pointee_info_at to this method and remove the old one?

Show resolved Hide resolved src/librustc/ty/layout.rs Outdated
Show resolved Hide resolved src/librustc/ty/layout.rs Outdated

ty::Ref(_, ty, mt) if offset.bytes() == 0 => {
let tcx = cx.tcx();
let is_freeze = ty.is_freeze(tcx, ty::ParamEnv::reveal_all(), DUMMY_SP);

This comment has been minimized.

@oli-obk

oli-obk Dec 28, 2018

Contributor

I don't know where pointee_info_at is called. But depending on where it's used it would make sense to pass in the param env as an argument and then just forward it here instead of assuming reveal_all

This comment has been minimized.

@wildarch

wildarch Dec 28, 2018

Contributor

Right now pointee_info_at is only used in librustc_codegen_llvm. This pull request would expand that to librustc_mir. I'm not familiar with the specifics of ParamEnv, but judging from the docs it would likely only be used with ParamEnv::reveal_all (it is only used after type-checking). So for the current use-case I don't think that extra flexibility is necessary. Would you still prefer to have this parameter in order to make it an explicit caller decision @oli-obk?

This comment has been minimized.

@oli-obk

oli-obk Dec 28, 2018

Contributor

If we're using it in librustc_mir, it is likely that we need to use other ParamEnvs. When calling generic const fns during const eval while evaluating an associated constant we'll definitely run into trouble here.

If there are very few use sites, it's not too much hazzle to just pass ParamEnv::reveal_all() at them for now

This comment has been minimized.

@wildarch

wildarch Dec 28, 2018

Contributor

Unfortunately I ran into a problem adding the ParamEnv argument to the function. The function pointee_info_at is declared in the trait TylayoutMethods in the rustc_target crate, whereas the ParamEnv struct lives in rustc. I could of course have rustc_target depend on rustc, but that would introduce a circular depedency between the crates.

I think the better solution would be to move the function declaration to somewhere in rustc together with the impl, but I do not know enough about the rust compiler internals to find an alternative trait to declare the function in. Any suggestions?

This comment has been minimized.

@oli-obk

oli-obk Dec 28, 2018

Contributor

Oh right. Curious situation.

You can break this by adding another associated type to

pub trait LayoutOf {
for the ParamEnv and then use that associated type. In rustc you can then insert the correct type

This comment has been minimized.

@wildarch

wildarch Dec 28, 2018

Contributor

An associated type, of course! I have added an associated type ParamEnv to TyLayoutMethods, the trait that also includes pointee_info_at. I think it makes more sense that way as opposed to adding the type to LayoutOf, as that last trait does not need the type itself. I can of course move it there if you have good reason to prefer it declared in LayoutOf @oli-obk? 😉

This comment has been minimized.

@oli-obk

oli-obk Dec 28, 2018

Contributor

Seems fine to me. I just thought it would make sense in LayoutOf for consistency. We can still move it there if needed in the future, so the status quo is fine with me

Show resolved Hide resolved src/librustc/ty/layout.rs Outdated
Show resolved Hide resolved src/librustc_target/abi/mod.rs

oli-obk and others added some commits Dec 28, 2018

Fix typo in src/librustc/ty/layout.rs
Co-Authored-By: wildarch <daandegraaf9@gmail.com>
Add param_env parameter to pointee_info_at.
An associated type ParamEnv has been added to TyLayoutMethods to
facilitate this.
@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Dec 28, 2018

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:1547a3e4:start=1546007169673648626,finish=1546007225209864498,duration=55536215872
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---

[00:03:44] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:45] tidy error: /checkout/src/librustc/ty/layout.rs:1864: line longer than 100 chars
[00:03:46] some tidy checks failed
[00:03:46] 
[00:03:46] 
[00:03:46] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:46] 
[00:03:46] 
[00:03:46] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:46] Build completed unsuccessfully in 0:00:45
[00:03:46] Build completed unsuccessfully in 0:00:45
[00:03:46] make: *** [tidy] Error 1
[00:03:46] Makefile:69: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0c21d938
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Fri Dec 28 14:31:00 UTC 2018
---
travis_time:end:095ec6a1:start=1546007461009059277,finish=1546007461015277412,duration=6218135
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:00a0c460
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:01e3a6d6
travis_time:start:01e3a6d6
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0260a7c8
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@wildarch

This comment has been minimized.

Copy link
Contributor

wildarch commented Jan 11, 2019

@eddyb I think the moving of pointee_info_at is now complete. I've been looking at your hints for further refactoring in #56166, which part of rustc_codegen_ssa are you referring to there?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment