Add "type_name" support in emulate_intrinsic() #61399

TankhouseAle · 2019-05-31T15:20:00Z

This allows it to be used in "const fn" contexts.

(It was suggested by /u/YatoRust on Reddit that I open a PR for this, so I am.)

It was suggested by /u/YatoRust on Reddit that I open a PR for this, so I am.

rust-highfive · 2019-05-31T15:20:11Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @michaelwoerister (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.

Centril · 2019-05-31T15:27:35Z

r? @oli-obk

rust-highfive · 2019-05-31T15:40:46Z

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:0e6283a2:start=1559316108597018992,finish=1559316109363674908,duration=766655916
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:04:43] tidy error: /checkout/src/librustc_mir/interpret/intrinsics.rs:87: trailing whitespace
[00:04:47] some tidy checks failed
[00:04:47] 
[00:04:47] 
[00:04:47] 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:04:47] 
[00:04:47] 
[00:04:47] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:47] Build completed unsuccessfully in 0:01:14
---
travis_time:end:03beea80:start=1559316409248499774,finish=1559316409252972948,duration=4473174
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:09c3f40b
$ 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:0cb9db52
travis_time:start:0cb9db52
$ 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:0eeafc0a
$ 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)

wesleywiser

I'd love to see a test added to src/test/run-pass/ctfe as well.

src/librustc_mir/interpret/intrinsics.rs

Centril · 2019-05-31T17:34:39Z

type_name as an fn is one thing, but type_name as a const fn is quite another. I'm fine with landing this as unstable but I want to hold off on stabilizing as a const fn until such time that we have dealt with:

control flow,
&mut T,
and bounds,

and have considered the implication of these together. Notably, const fns would have no longer have any ability to enforce referential transparency for generic functions if you introduce 1 + 2 + const fn type_name. Moreover, we have not constified Any yet so we should consider that as well before const fn type_name.

"name_val" seem more consistent with the variable naming in the surrounding code.

TankhouseAle · 2019-05-31T19:09:36Z

I'd love to see a test added to src/test/run-pass/ctfe as well.

Added one just now.

src/test/run-pass/ctfe/const-fn-type-name.rs

Also, use core::intrinsics::type_name instead of std::intrinsics::type_name, which I don't think makes any real difference but seems like it's probably more logical.

rust-highfive · 2019-05-31T20:55:10Z

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:10c72a58:start=1559332163394254279,finish=1559332165463879906,duration=2069625627
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:59:28] .............................................................................i...................... 200/2923
[00:59:37] .................................................................................................... 300/2923
[00:59:47] .................................................................................................... 400/2923
[00:59:57] .................................................................................................... 500/2923
[01:00:08] ..............................................F..................................................... 600/2923
[01:00:34] .................................................................................................... 800/2923
[01:00:43] .................................................................................................... 900/2923
[01:00:57] .................................................................................................... 1000/2923
[01:01:09] .................................................................................................... 1100/2923
---
[01:05:29] ------------------------------------------
[01:05:29] stderr:
[01:05:29] ------------------------------------------
[01:05:29] thread 'main' panicked at 'assertion failed: `(left == right)`
[01:05:29]   left: `"Struct<i8, f64, bool>"`,
[01:05:29]  right: `"const_fn_type_name::Struct<i8, f64, bool>"`', /checkout/src/test/run-pass/ctfe/const-fn-type-name.rs:36:5
[01:05:29] 
[01:05:29] ------------------------------------------
[01:05:29] 
[01:05:29] 
---
[01:05:29] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:521:22
[01:05:29] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[01:05:29] 
[01:05:29] 
[01:05:29] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:05:29] 
[01:05:29] 
[01:05:29] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:05:29] Build completed unsuccessfully in 1:00:31
---
travis_time:end:0d853e52:start=1559336106688570620,finish=1559336106694924885,duration=6354265
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0013d3af
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checko

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)

TankhouseAle · 2019-05-31T22:12:04Z

Hmm, looks like there was a very recent change to what type_name() outputs in the normal case, that I didn't notice. Will have to change my implementation a bit.

Hopefully I didn't miss anything here.

rust-highfive · 2019-05-31T22:52:53Z

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:12165780:start=1559342009982972866,finish=1559342103568658264,duration=93585685398
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:14:29]    Compiling rustc_typeck v0.0.0 (/checkout/src/librustc_typeck)
[00:14:42] error[E0308]: mismatched types
[00:14:42]   --> src/librustc_mir/interpret/intrinsics.rs:84:41
[00:14:42]    |
[00:14:42] 84 |                 let ty_name = type_name(self.tcx, ty).ty.to_string();
[00:14:42]    |                                         |
[00:14:42]    |                                         expected struct `rustc::ty::TyCtxt`, found struct `rustc::ty::query::TyCtxtAt`
[00:14:42]    |                                         help: consider dereferencing the type: `*self.tcx`
[00:14:42]    |
---
travis_time:end:004a742c:start=1559343169323756185,finish=1559343169328353283,duration=4597098
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1d6cab40
$ 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:2922a3ec
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/li

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)

rust-highfive · 2019-06-01T01:35:26Z

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:24a73e2e:start=1559348876747567560,finish=1559348975741547693,duration=98993980133
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:59:38] .............................................................................i...................... 200/2924
[00:59:47] .................................................................................................... 300/2924
[00:59:58] .................................................................................................... 400/2924
[01:00:07] .................................................................................................... 500/2924
[01:00:18] ...............................................F.................................................... 600/2924
[01:00:44] .................................................................................................... 800/2924
[01:00:53] .................................................................................................... 900/2924
[01:01:07] .................................................................................................... 1000/2924
[01:01:19] .................................................................................................... 1100/2924
---
[01:05:35] ------------------------------------------
[01:05:35] stderr:
[01:05:35] ------------------------------------------
[01:05:35] thread 'main' panicked at 'assertion failed: `(left == right)`
[01:05:35]   left: `"&\'static str"`,
[01:05:35]  right: `"const_fn_type_name::Struct<i8, f64, bool>"`', /checkout/src/test/run-pass/ctfe/const-fn-type-name.rs:36:5
[01:05:35] 
[01:05:35] ------------------------------------------
[01:05:35] 
[01:05:35] 
---
[01:05:35] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:521:22
[01:05:35] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[01:05:35] 
[01:05:35] 
[01:05:35] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:05:35] 
[01:05:35] 
[01:05:35] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:05:35] Build completed unsuccessfully in 1:01:18
---
travis_time:end:14ab1c0f:start=1559352921937355544,finish=1559352921942133706,duration=4778162
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:07d521d7
$ 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:03866620
travis_time:start:03866620
$ 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:02370a36
$ 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)

I *think* this actually does, though!

TankhouseAle · 2019-06-01T13:20:09Z

type_name as an fn is one thing, but type_name as a const fn is quite another. I'm fine with landing this as unstable but I want to hold off on stabilizing as a const fn until such time that we have dealt with:

control flow,

&mut T,

and bounds,

and have considered the implication of these together. Notably, const fns would have no longer have any ability to enforce referential transparency for generic functions if you introduce 1 + 2 + const fn type_name. Moreover, we have not constified Any yet so we should consider that as well before const fn type_name.

To be clear, my PR does not include any actual built-in const fn wrapper for type_name() (other than the one implemented in the test file.)

It just allows people who are specifically using nightly to be able to write their own const fn wrappers for it, in conjunction with #![feature(core_intrinsics)] and #![feature(const_fn)].

Intrinsics are AFAIK all unstable forever anyways, so I don't think you currently could "stabilize" anything in this regard even if you wanted to.

Additionally, I'm not sure that I see a strong relationship between the typecasty runtime dynamism of the Any trait and what type_name() provides (at compile time, making it viable for high performance debugging / logging / e.t.c. related functions and such.)

oli-obk

Additionally, I'm not sure that I see a strong relationship between the typecasty runtime dynamism of the Any trait and what type_name() provides (at compile time, making it viable for high performance debugging / logging / e.t.c. related functions and such.)

😆 the reddit post you linked to shows a typecast example

Not to worry though, I am certain this is fine as an intrinsic.

Though I am 100% behind @Centril in the notion that we shouldn't stabilize a const fn wrapper for the type_name intrinsic without an RFC discussing the interaction of this feature together with other const eval features.

I'm not sure how useful this PR is when it will not result in anything stabilizeable for at least a year, but I won't block it on that.

oli-obk · 2019-06-02T18:33:23Z

src/librustc_mir/interpret/intrinsics.rs

+                } = const_val
+                {
+                    // unsafe for from_utf8_unchecked()
+                    unsafe {


please get rid of str_to_immediate, it is only used in miri's implementation of type_name and thus not needed.

Instead, you can write

let alloc_id = self.tcx.alloc_map.lock().create_memory_alloc(data); let name_val = Immediate::new_slice(Scalar::Ptr(ptr.into()), data.len(), self);

The code as currently written would be invalid when encountering a ConstValue::Slice where start != 0 or end - start != data.len(). The way type_name is written, that doesn't happen, so... idk, add some comments explaining why that's ok?

Maybe it would also simplify things if you pulled out

rust/src/librustc_mir/interpret/intrinsics/type_name.rs

Lines 216 to 219 in 0f0ad45

let path = AbsolutePathPrinter { tcx, path: String::new() }.print_type(ty).unwrap().path;

let len = path.len();

let alloc = Allocation::from_byte_aligned_bytes(path.into_bytes(), ());

let alloc = tcx.intern_const_alloc(alloc);

into a separate function (with pub(super) visibility) and called that here? That way we'd not have the ConstValue::Slice wrapper and could simplify the code shown above to

let alloc_id = self.tcx.alloc_map.lock().create_memory_alloc(data); let name_val = Immediate::new_slice(Scalar::Ptr(ptr.into()), data.len(), self);

😆 the reddit post you linked to shows a typecast example

Yeah. As I believe I stated in there though, I don't think those are particularly realistic use cases for what someone who is using compile-time intrinsics at all is likely to want to do with this kind of function.

I was quite literally unaware the "breaking parametricity" thing was a concern that anyone had at all before being told about it by a few people in that thread, as the general concept of doing something like that hadn't ever crossed my mind.

With regards to the changes, I'll work on them now (I didn't notice you had replied until right after I sent off the minor commit I just made, haha.)

Thanks for the review!

Also make it more clear we're talking about the `librustc_mir`-specific function called `type_name()` in the bug message.

rust-highfive · 2019-06-02T20:29:11Z

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:07ce6130:start=1559506235487253461,finish=1559506324824055396,duration=89336801935
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55

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)

TankhouseAle · 2019-06-02T20:39:44Z

(Ignore the last commit, basically.)

I hope this works like I think it does!

I feel like the function name is good, so just knocking it down a line seems like the right way to go.

rust-highfive · 2019-06-03T01:31:48Z

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:00049e58:start=1559524486075672253,finish=1559524573544230705,duration=87468558452
$ 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
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:03:49] tidy error: /checkout/src/librustc_mir/interpret/intrinsics/type_name.rs:231: trailing whitespace
[00:03:54] some tidy checks failed
[00:03:54] 
[00:03:54] 
[00:03:54] 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:54] 
[00:03:54] 
[00:03:54] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:54] Build completed unsuccessfully in 0:01:14
---
travis_time:end:01d81707:start=1559524817854300301,finish=1559524817859207410,duration=4907109
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:027bf5e0
$ 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:218920ad
travis_time:start:218920ad
$ 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:09872cfd
$ 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)

Within `tag_static_base_pointer`, that is. The separate `id_ptr` variable *does* seem to be necessary in general, however. Trying to do `name_id.into()` *directly* inside of `Scalar::Ptr()` in this context fails to compile, as `rustc` wants this super-specific specialization of `Pointer` which it apparently doesn't get from that.

src/librustc_mir/interpret/intrinsics/type_name.rs

oli-obk · 2019-06-03T07:25:39Z

just one more nit then this lgtm. Can you also squash the commits?

src/librustc_mir/interpret/intrinsics.rs

src/test/run-pass/ctfe/const-fn-type-name.rs

RalfJung · 2019-06-03T08:14:35Z

Notably, const fns would have no longer have any ability to enforce referential transparency for generic functions if you introduce 1 + 2 + const fn type_name. Moreover, we have not constified Any yet so we should consider that as well before const fn type_name.

I don't think there is a direct connection to referential transparency here. There is a possibility to violate parametricity for types, but that's nothing new for Rust and specialization will let us do that, too. The type cast example is a typical parametricity violation.

There are so many problems with making parametricity violations UB that I don't think that is a realistic option. As a starter, it is entirely uncheckable even dynamically.

And also fix the formatting.

Merge

Merge again

RalfJung · 2019-06-03T18:36:56Z

Uh... what?^^ Why did you close this?

TankhouseAle · 2019-06-03T19:02:15Z

Uh... what?^^ Why did you close this?

Sorry about that. Kinda got myself into a mess with the commit history.

I'm admittedly not super experienced with Git, and was trying to see if there was a reasonable way to "squash" the commit history from the web interface as I don't have access to my local repo with actual Git tools where I am right now.

It seems there is not! (At least that I could find.) See here for the reopened issue.

TankhouseAle · 2019-06-03T20:48:40Z

Looks like the build finished successfully over there. Was there anything else you needed on my end?

…oli-obk Add "type_name" support in emulate_intrinsic() I did some dumb Git things and deleted my original fork repo semi-accidentally (but probably for the best as I'd messed up the history.) This is the same issue as rust-lang#61399, which was obviously auto-closed, to be clear.

Add "type_name" support in emulate_intrinsic() I did some dumb Git things and deleted my original fork repo semi-accidentally (but probably for the best as I'd messed up the history.) This is the same issue as #61399, which was obviously auto-closed, to be clear.

Add "type_name" support in emulate_intrinsic()

d3d82b0

It was suggested by /u/YatoRust on Reddit that I open a PR for this, so I am.

rust-highfive assigned michaelwoerister May 31, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 31, 2019

rust-highfive assigned oli-obk and unassigned michaelwoerister May 31, 2019

wesleywiser reviewed May 31, 2019

View reviewed changes

src/librustc_mir/interpret/intrinsics.rs Outdated Show resolved Hide resolved

src/librustc_mir/interpret/intrinsics.rs Outdated Show resolved Hide resolved

TankhouseAle added 2 commits May 31, 2019 14:16

Fix whitespace, change "value" to "name_val"

271cf97

"name_val" seem more consistent with the variable naming in the surrounding code.

Add a test, as suggested.

67b3fde

wesleywiser reviewed May 31, 2019

View reviewed changes

src/test/run-pass/ctfe/const-fn-type-name.rs Outdated Show resolved Hide resolved

Do an actual check with assert_eq, as suggested.

d0cc41d

Also, use core::intrinsics::type_name instead of std::intrinsics::type_name, which I don't think makes any real difference but seems like it's probably more logical.

Adapt implementation to "deterministic type_name"

d6e63a3

Hopefully I didn't miss anything here.

We need "tcx.tcx", not just "tcx"

cce1392

TankhouseAle added 2 commits May 31, 2019 23:10

The last commit certainly didn't do what I thought it did.

82215e2

I *think* this actually does, though!

Can't have ConstValue without ConstValue!

0f0ad45

oli-obk requested changes Jun 2, 2019

View reviewed changes

Move a brace up to be more consistent.

892bc65

Also make it more clear we're talking about the `librustc_mir`-specific function called `type_name()` in the bug message.

TankhouseAle added 2 commits June 2, 2019 20:02

Add the suggested utility function to type_name.rs

19a3814

Use the new function to implement type_name

11da537

I hope this works like I think it does!

TankhouseAle added 2 commits June 2, 2019 21:10

Make Tidy happy

dfb8dbd

I feel like the function name is good, so just knocking it down a line seems like the right way to go.

Make Tidy happy

04736f5

TankhouseAle added 2 commits June 2, 2019 21:32

Literally just remove a single space

c326ef1

This was referenced Jun 3, 2019

Make the type_name intrinsic deterministic #60166

Merged

Add a test for the new type_name intrinsic. rust-lang/miri#761

Merged

oli-obk reviewed Jun 3, 2019

View reviewed changes

src/librustc_mir/interpret/intrinsics/type_name.rs Outdated Show resolved Hide resolved

RalfJung reviewed Jun 3, 2019

View reviewed changes

src/librustc_mir/interpret/intrinsics.rs Show resolved Hide resolved

RalfJung reviewed Jun 3, 2019

View reviewed changes

src/test/run-pass/ctfe/const-fn-type-name.rs Show resolved Hide resolved

TankhouseAle added 6 commits June 3, 2019 09:21

Add line break as suggested

04946c7

Use alloc_type_name() in type_name()

9a0c77c

And also fix the formatting.

Maybe it will merge this way?

9b2d648

Change this back temporarily

0a9047b

Merge pull request #2 from rust-lang/master

c3ef5a5

Merge

Put my changes back in

43ba61a

vertexclique mentioned this pull request Jun 3, 2019

Remove promoted intrinsics caller type checking from const context #61493

Closed

TankhouseAle added 3 commits June 3, 2019 14:14

Fix duplicated bounds printing in rustdoc (#4)

1c8ce6d

Update from master

430f4a6

Merge pull request #8 from rust-lang/master

bbb209d

Merge again

TankhouseAle closed this Jun 3, 2019

TankhouseAle deleted the const-fn-type-name branch June 3, 2019 18:30

TankhouseAle mentioned this pull request Jun 3, 2019

Add "type_name" support in emulate_intrinsic() #61498

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add "type_name" support in emulate_intrinsic() #61399

Add "type_name" support in emulate_intrinsic() #61399

TankhouseAle commented May 31, 2019 •

edited

Loading

rust-highfive commented May 31, 2019

Centril commented May 31, 2019

rust-highfive commented May 31, 2019

wesleywiser left a comment •

edited

Loading

Centril commented May 31, 2019

TankhouseAle commented May 31, 2019

rust-highfive commented May 31, 2019

TankhouseAle commented May 31, 2019 •

edited

Loading

rust-highfive commented May 31, 2019

rust-highfive commented Jun 1, 2019

TankhouseAle commented Jun 1, 2019 •

edited

Loading

oli-obk left a comment

oli-obk Jun 2, 2019

oli-obk Jun 2, 2019

TankhouseAle Jun 2, 2019 •

edited

Loading

rust-highfive commented Jun 2, 2019

TankhouseAle commented Jun 2, 2019

rust-highfive commented Jun 3, 2019

oli-obk commented Jun 3, 2019

RalfJung commented Jun 3, 2019

RalfJung commented Jun 3, 2019

TankhouseAle commented Jun 3, 2019 •

edited

Loading

TankhouseAle commented Jun 3, 2019

	let path = AbsolutePathPrinter { tcx, path: String::new() }.print_type(ty).unwrap().path;
	let len = path.len();
	let alloc = Allocation::from_byte_aligned_bytes(path.into_bytes(), ());
	let alloc = tcx.intern_const_alloc(alloc);

Add "type_name" support in emulate_intrinsic() #61399

Add "type_name" support in emulate_intrinsic() #61399

Conversation

TankhouseAle commented May 31, 2019 • edited Loading

rust-highfive commented May 31, 2019

Centril commented May 31, 2019

rust-highfive commented May 31, 2019

wesleywiser left a comment • edited Loading

Choose a reason for hiding this comment

Centril commented May 31, 2019

TankhouseAle commented May 31, 2019

rust-highfive commented May 31, 2019

TankhouseAle commented May 31, 2019 • edited Loading

rust-highfive commented May 31, 2019

rust-highfive commented Jun 1, 2019

TankhouseAle commented Jun 1, 2019 • edited Loading

oli-obk left a comment

Choose a reason for hiding this comment

oli-obk Jun 2, 2019

Choose a reason for hiding this comment

oli-obk Jun 2, 2019

Choose a reason for hiding this comment

TankhouseAle Jun 2, 2019 • edited Loading

Choose a reason for hiding this comment

rust-highfive commented Jun 2, 2019

TankhouseAle commented Jun 2, 2019

rust-highfive commented Jun 3, 2019

oli-obk commented Jun 3, 2019

RalfJung commented Jun 3, 2019

RalfJung commented Jun 3, 2019

TankhouseAle commented Jun 3, 2019 • edited Loading

TankhouseAle commented Jun 3, 2019

TankhouseAle commented May 31, 2019 •

edited

Loading

wesleywiser left a comment •

edited

Loading

TankhouseAle commented May 31, 2019 •

edited

Loading

TankhouseAle commented Jun 1, 2019 •

edited

Loading

TankhouseAle Jun 2, 2019 •

edited

Loading

TankhouseAle commented Jun 3, 2019 •

edited

Loading