Stream: t-compiler/const-eval

Topic: Project ideas


ecstatic-morse (Dec 16 2019 at 21:04, on Zulip):

@WG-const-eval Which CTFE-related features would you like to see worked on going forward? Here are a few off the top of my head.

There's also some tasks that don't involve design work like:

It would be cool to know what people want to prioritize next year.

oli (Dec 16 2019 at 21:05, on Zulip):

@Christian Poveda is looking at mut references I believe

oli (Dec 16 2019 at 21:05, on Zulip):

I don't think we can even start on heap without at least an e-RFC

Christian Poveda (Dec 16 2019 at 21:06, on Zulip):

Christian Poveda is looking at mut references I believe

yes we have a feature gate for that now

ecstatic-morse (Dec 16 2019 at 21:06, on Zulip):

True, &mut is pretty close, although this is a bit concerning:

ecstatic-morse (Dec 16 2019 at 21:07, on Zulip):

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4371a0cf7245a7d235cb2b8809b0bb10

oli (Dec 16 2019 at 21:07, on Zulip):

It's probably unsound, so I presume that's what @ecstatic-morse means

oli (Dec 16 2019 at 21:07, on Zulip):

ROFL yea, constants are bad

ecstatic-morse (Dec 16 2019 at 21:08, on Zulip):

The others would all require RFCs, depending on how narrowly we want to address #66753

oli (Dec 16 2019 at 21:08, on Zulip):

Maybe we need ConstSafe even before heap

ecstatic-morse (Dec 16 2019 at 21:08, on Zulip):

But I recall that const trait methods have had a lot of design work and are (maybe?) pretty close

ecstatic-morse (Dec 16 2019 at 21:10, on Zulip):

If I could pick one feature from the list above, it would probably be that one. Even though it's a ton of work and a pretty profound change to the language

oli (Dec 16 2019 at 21:11, on Zulip):

Yes, I have an RFC and the status is that T-lang discussed it and is basically fine with it being an experimental feature, but I'm waiting for public confirmation of this before doing any work on it. Otherwise an open PR would put pressure on the RFC being handled faster

Christian Poveda (Dec 16 2019 at 21:11, on Zulip):

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4371a0cf7245a7d235cb2b8809b0bb10

I'll take a look at this

oli (Dec 16 2019 at 21:12, on Zulip):

Maybe we could implement ?const Trait first, because that is the behaviour of current trait bounds with const_fn enabled

oli (Dec 16 2019 at 21:12, on Zulip):

@Christian Poveda read the const heap tracking issue

oli (Dec 16 2019 at 21:13, on Zulip):

It has similar problems

Christian Poveda (Dec 16 2019 at 21:13, on Zulip):

that's funny, I wanted to get involved with const heap :P

oli (Dec 16 2019 at 21:15, on Zulip):

There's no real difference between Box<T> and &mut T if it's in a global thing

ecstatic-morse (Dec 16 2019 at 21:15, on Zulip):

I think the current RFC process is lacking when it comes to really big changes like const trait methods. It's better for small changes that don't need a lot of experimentation. The process laid out in nikomatsakis' blog post would be a much better fit.

oli (Dec 16 2019 at 21:16, on Zulip):

Ooh new RFC process blog posts. It's been a while

ecstatic-morse (Dec 16 2019 at 21:18, on Zulip):

Can anyone think of an obvious feature/work-item that I've missed?

ecstatic-morse (Dec 16 2019 at 21:19, on Zulip):

I guess there's always "pay down technical debt", which I've been doing a bit of in the const-checking arena.

ecstatic-morse (Dec 16 2019 at 21:20, on Zulip):

But that isn't very inspiring XD

oli (Dec 16 2019 at 21:20, on Zulip):

A bit is a bit of an understatement. That's some amazing cleanup duty you've taken up

Christian Poveda (Dec 16 2019 at 21:20, on Zulip):

yeah code janitoring is underrated

oli (Dec 16 2019 at 21:21, on Zulip):

I'll think about what cool features are still missing in const eval. I think you covered the big ones. For now I'm going to bed. Oh one thought that I just had was side effects like emitting warnings on purpose or emitting artifacts.

oli (Dec 16 2019 at 21:22, on Zulip):

Also type declarations by const eval emitting a TyLayout equivalent

oli (Dec 16 2019 at 21:22, on Zulip):

So what proc macros did for codegen, const eval could do for type declarations

oli (Dec 16 2019 at 21:23, on Zulip):

Procedural types

oli (Dec 16 2019 at 21:23, on Zulip):

(Including their layout "obviously")

oli (Dec 16 2019 at 21:23, on Zulip):

Ok

oli (Dec 16 2019 at 21:23, on Zulip):

Bed

oli (Dec 16 2019 at 21:23, on Zulip):

Really this time

Christian Poveda (Dec 16 2019 at 21:23, on Zulip):

:sleeping:

ecstatic-morse (Dec 16 2019 at 21:23, on Zulip):

Yeah artifacts would be very cool. Perfect hash functions with no build script. Goodnight! Sorry for nerd sniping.

oli (Dec 17 2019 at 11:28, on Zulip):

Why do perfect hash functions need artifacts? I thought they were for use inside a program, so all you'd need to do is compute the hash table... oh and the hash function parameters. Or do we need to generate an entire function for performance reasons?

oli (Dec 17 2019 at 11:29, on Zulip):

Maybe we can just fill in associated constants and make a single generic function that is then optimized to the perfect hash function

oli (Dec 17 2019 at 11:29, on Zulip):

/me knows nothing about PHF

ecstatic-morse (Dec 17 2019 at 20:54, on Zulip):

Isn't static: &mut i32 a data race waiting to happen?

ecstatic-morse (Dec 17 2019 at 20:55, on Zulip):

It's basically a static mut with no unsafe required

ecstatic-morse (Dec 17 2019 at 20:56, on Zulip):

I guess &mut isn't copyable, so maybe that helps?

ecstatic-morse (Dec 17 2019 at 21:00, on Zulip):

Whoops wrong thread

ecstatic-morse (Dec 17 2019 at 23:00, on Zulip):

There's some more advanced perfect hash function generators that vary the class of hash function based on the input. You're right that the vast majority wouldn't require artifacts. It was the first thing that popped into my head.

ecstatic-morse (Dec 17 2019 at 23:00, on Zulip):

I might actually try to implement a non-proc-macro PHF generator. Seems kind of fun!

oli (Dec 18 2019 at 13:44, on Zulip):

You can vary the hash function class by "indexing". Implement the different classes by making them traits on arrays. Each class is a different array length. Choose the algorithm via the index

oli (Dec 19 2019 at 21:01, on Zulip):

@ecstatic-morse we have a yellow light on implementing the const trait bounds RFC

oli (Dec 19 2019 at 21:02, on Zulip):

Even with the RFC still open, an unstable experiment is now permitted

ecstatic-morse (Dec 19 2019 at 21:05, on Zulip):

Cool! I'm happy to help implement, although it will not touch any code that I'm familiar with. Also I won't have much time until after the holidays. I'm mobile only for the next few days XD. I'll reread the draft RFC

oli (Dec 20 2019 at 06:37, on Zulip):

yea no rush, if you want we can make an impl brainstorm meeting

oli (Dec 20 2019 at 06:37, on Zulip):

I have ideas how to get there in small steps, which should also help not requiring you to modify the entire compiler everyhwere

ecstatic-morse (Dec 20 2019 at 07:08, on Zulip):

Sounds good. I'll be back at full availability after Christmas on the 30th. Anytime after that would be fine for a meeting.

oli (Dec 20 2019 at 07:15, on Zulip):

:+1: ok, I'm not sure how available I am between 30th and 7th

oli (Dec 20 2019 at 07:15, on Zulip):

we'll find sth

centril (Dec 25 2019 at 03:22, on Zulip):

I'm happy to review the parser changes :slight_smile:

ecstatic-morse (Jan 03 2020 at 02:10, on Zulip):

@oli I implemented a perfect hash function generator that runs entirely during const-eval. It's not very robust (it's a heuristically guided random search loosely based on gperf), but my intention was to get an idea of the most painful parts of writing complex code in a const context.

ecstatic-morse (Jan 03 2020 at 02:12, on Zulip):

(computing a PHF for the set of rust keywords takes around a second and completes just after the loop detector is triggered)

ecstatic-morse (Jan 03 2020 at 02:14, on Zulip):

The experience reaffirmed my belief that calling trait methods in const contexts is the next major roadblock. Writing code without for-loops or range-based/custom indexing is not fun.

ecstatic-morse (Jan 03 2020 at 02:21, on Zulip):

I ended up using a stack-only dynamic array a lot. Constification of ptr::write and MaybeUninit would allow pretty much all of staticvec to be const if const trait impls were implemented. I ended up rolling my own version that required T: Copy, needed an initial value and still had UB during initialization.

ecstatic-morse (Jan 03 2020 at 02:25, on Zulip):

The other concern I have is the lack of unwrap/expect. I think it is likely that library authors will resort to extensions like fn unwrap<T: Copy>(x: Option<T>) -> T. However, as you pointed out on that issue, I doubt there will ever be a way to implement const Option::<T>::unwrap for all Twithout awful hacks.

ecstatic-morse (Jan 03 2020 at 02:28, on Zulip):

In fact, the need for these two methods was so acute that I am now in favor of doing a mem::forget-style hack to make them const fn on Option and Result. Others will no doubt disagree.

ecstatic-morse (Jan 03 2020 at 02:39, on Zulip):

The ? operator would also be desirable, although I did not run into this quite as much, and it would require the same hacks as for unwrap as well as const trait impls.

Last update: Jan 28 2020 at 01:15UTC