Stream: t-compiler/const-eval

Topic: intrinsic-promotion


oli (Jun 03 2019 at 16:45, on Zulip):

@eddyb there's now https://github.com/rust-lang/rust/pull/61493

Mahmut Bulut (Jun 17 2019 at 07:02, on Zulip):

Fyi, I will rebase my pr today and address things that you've commented over. https://github.com/rust-lang/rust/pull/61835

vertexclique (Aug 28 2019 at 10:06, on Zulip):

Hi all, I will get back to this PR asap. (if there is no problem blocking it)

oli (Aug 28 2019 at 10:54, on Zulip):

cool

oli (Aug 28 2019 at 10:54, on Zulip):

note that a bunch of stuff changed in the background and is changing (there are a few open PRs)

oli (Aug 28 2019 at 10:55, on Zulip):

so doing it in the smallest possible steps would be good to not cause much churn

vertexclique (Sep 04 2019 at 07:51, on Zulip):

Can somebody explain to me about "promotion" and "evaluability" in this context? If I understand correctly, promotion is enabling/disabling evaluability for specific function(in this context's case some instrinsics) in const context when const declaration happens. Is it correct? What is more correct? I am lost in terms.

oli (Sep 04 2019 at 09:12, on Zulip):

Promotion is generating an unnameable static from runtime code

oli (Sep 04 2019 at 09:13, on Zulip):

Evaluability is whether some piece of code can be processed by const eval

oli (Sep 04 2019 at 09:13, on Zulip):

Promotion requires evaluability but is much stronger

oli (Sep 04 2019 at 09:13, on Zulip):

Intrinsics should never be promotable, but can be evaluable

RalfJ (Sep 15 2019 at 12:52, on Zulip):

@vertexclique also see https://github.com/rust-rfcs/const-eval/

RalfJ (Sep 15 2019 at 12:52, on Zulip):

but the documents there are still being worked on

RalfJ (Sep 15 2019 at 12:53, on Zulip):

in particular we are looking for some terminology

RalfJ (Sep 15 2019 at 12:53, on Zulip):

and I got no feedback at all on that my proposal there :/
@oli @eddyb any comments?

vertexclique (Sep 23 2019 at 08:22, on Zulip):

I think I need to take a look at this change and refactor things again?
https://github.com/rust-lang/rust/pull/64683

vertexclique (Sep 23 2019 at 08:22, on Zulip):

Should I wait for the merge or rebase later?

oli (Sep 24 2019 at 08:11, on Zulip):

That PR is blocked on your changes, so... :D

vertexclique (Sep 24 2019 at 08:46, on Zulip):

OOF my bad. :face_palm:

vertexclique (Sep 24 2019 at 10:32, on Zulip):

I have reopened the PR. Solved conflicts.

vertexclique (Sep 24 2019 at 10:33, on Zulip):

Last time const_transmute feature gate was ignored at the caller site.

vertexclique (Sep 24 2019 at 10:34, on Zulip):

I don't know how to fix that rn. I am adding the tests.

vertexclique (Sep 24 2019 at 14:37, on Zulip):

I am at work btw. Will look at your comments @oli

oli (Sep 24 2019 at 14:46, on Zulip):

no pressure. That's what we have github for, async communication

vertexclique (Sep 28 2019 at 12:29, on Zulip):

I have a problem with const_transmute. I have removed that feature from active. Should I move it to removed? How I can disable it because

#[rustc_const_unstable(feature = "const_transmute")]

is creating problem on compilation and makes const_transmute tests fail.
Long story short I want to reenable const_transmute gate that we had disabled before.

vertexclique (Sep 28 2019 at 12:29, on Zulip):

@oli any idea on this?

oli (Sep 28 2019 at 12:30, on Zulip):

you should remove it entirely I think? The rustc_const_unstable will generate its own feature gate names

oli (Sep 28 2019 at 12:31, on Zulip):

is creating problem on compilation and makes const_transmute tests fail.

Do you have the errors at hand?

vertexclique (Sep 28 2019 at 12:31, on Zulip):

recompiling now I will write here.

vertexclique (Sep 28 2019 at 12:55, on Zulip):
thread 'rustc' panicked at 'assertion failed: !self.tcx.is_const_fn(def_id)', src/librustc_mir/transform/qualify_consts.rs:1286:29
stack backtrace:

@oli

vertexclique (Sep 28 2019 at 12:57, on Zulip):

this is caused by early return to not check that const fn for intrinsics

oli (Sep 28 2019 at 13:02, on Zulip):

oh, just swap the condition

oli (Sep 28 2019 at 13:02, on Zulip):

we want to check now that the intrinsic is "const fn"

vertexclique (Sep 28 2019 at 14:15, on Zulip):

transmute tests are getting compiled. sigh

vertexclique (Sep 28 2019 at 14:16, on Zulip):

Also changed my local test to what @RalfJ commented.

oli (Sep 28 2019 at 14:18, on Zulip):

uh

oli (Sep 28 2019 at 14:18, on Zulip):

sorry

oli (Sep 28 2019 at 14:18, on Zulip):

I should have been clearer

oli (Sep 28 2019 at 14:18, on Zulip):

swap the assert!

oli (Sep 28 2019 at 14:19, on Zulip):

I want the assert to trigger if we call an intrinsic that is not in the list

vertexclique (Sep 28 2019 at 14:55, on Zulip):

I've negated the assert before but it gives ice.

vertexclique (Sep 28 2019 at 14:56, on Zulip):

I've tried again. It gave ice again. Seems like there is a usage for both transmute and other intrinsics in the codebase.

oli (Sep 28 2019 at 14:57, on Zulip):

you can print more info on the assert

oli (Sep 28 2019 at 14:57, on Zulip):

e.g. tcx.item_name(def_id) or so

oli (Sep 28 2019 at 14:58, on Zulip):

assert!(condition, "{}", tcx.item_name(def_id))

vertexclique (Sep 28 2019 at 14:58, on Zulip):

oh ok so we expect it. _gets enlightened_

oli (Sep 28 2019 at 14:58, on Zulip):

this way you see which intrinsic it is and can add it to the list

vertexclique (Sep 28 2019 at 14:59, on Zulip):

ok thanks let me check.

oli (Sep 28 2019 at 14:59, on Zulip):

we want is_const_fn to return true for whitelisted intrinsics, so the assert should trigger, but I don't know why it's triggering for you

vertexclique (Sep 28 2019 at 15:12, on Zulip):

It is mem::size_of but it is in platform intrinsics list.

oli (Sep 28 2019 at 15:16, on Zulip):

huh?

oli (Sep 28 2019 at 15:16, on Zulip):

it should be a normal intrinsic

oli (Sep 28 2019 at 15:17, on Zulip):

can you push the full code so I can have a look?

vertexclique (Sep 28 2019 at 15:17, on Zulip):

recompiling now I got you wrong when you said swap the condition. I negated the is_const_intrinsic, you already have commented on that.

vertexclique (Sep 28 2019 at 15:17, on Zulip):

yes in a sec.

vertexclique (Sep 28 2019 at 15:55, on Zulip):

pushed. btw even match arm has RustIntrinsic pattern I got: intrinsic 'maxnumf32' is not in whitelist.

vertexclique (Sep 28 2019 at 16:06, on Zulip):

+ maxnumf32/f64 and more aren't in const intrinsics whitelist

vertexclique (Sep 28 2019 at 20:06, on Zulip):

@oli I might have interpreted you wrong again. scratching my head here.

vertexclique (Oct 06 2019 at 13:16, on Zulip):

had no time to debug what is happening in the branch.

Last update: Nov 15 2019 at 21:00UTC