Constants involving dereferencing in pattern matching

[IvanUkhov]

Constants that dereference string literals cannot be currently used for pattern matching as show below:

const A: [u8; 4] = *b"fooo";

fn main() {
    match *b"xxxx" {
        A => {},
        _ => {}
    }
}

Such constants can be used in other contexts without any problem. It is inconsistent, and a very prominent use case is missing.

[ghost]

A rather easy task for a new compiler hacker (const_eval::const_expr_to_pat).

[barca]

I would love to try take a work on this, plus I would qualify as a new compiler hacker. I've been going through the code linked above, and I have some idea of what to do, although I will undoubtedly have questions later.

[ghost]

@barca Happy to mentor, let me know how it goes! Thanks!

[barca]

@jakub- While I'm fairly confident about the code I've written to solve this issue, However I'm running into the issue of compiling the language from source. Its extremely slow to compile, and quite frustrating when a serious error occurs(which has unfortunately happened quite frequently). I was wondering if you had any tricks for speeding up this overall process. Thanks

[barca]

@jakub- So, I've been struggling with this issue, but have been actively working on it. up until now I have been trying to dereference the u8 literals or the vec that holds them, however have been unsuccessful in this. While it is more than possible that I have made a mistake in my implementation, I was wondering if you had an idea of how to approach this issue.

[brson]

@pnkfelix @eddyb @nrc Any suggestions on how to proceed here? @barca posting your patch would probably help.

[nrc]

@barca on slow compiles, there's a few things you can do, make sure you're building with -j8 (you'll have to experiment with the exact number of jobs to find the optimal number for your machine) and only build the stage1 compiler (make rustc-stage1) rather than the full bootstrap. You can then test using the stage1 build and only do a full bootstrap when you are happy with your work. Other than that, long build times are just part of life for rust compiler hackers, sorry.

[nrc]

@barca please post your patch and I'll take a look, hard for me to know exactly what the problem is without seeing the code.

[barca]

@nrc thanks, I was able to find some blogs, I've been doing 4 jobs seems to work fast enough.
here's my code. I could be very wrong in my approach, and would appreciate any advice.

[nrc]

@barca I think you're pretty much on the right track. The pattern you end up with should be a PatLit wrapping an ExprVec, then you just need to convert your Vec of u8s into a Vec of LitInts (wrapped in ExprInts). There will be a little bit of a dance with P(..) to do that. Does that get you unstuck?

[barca]

@nrc thats very helpful, thanks so much. people like you and @brson make me love rust!

[nrc]

❤️

@barca ping me on irc if you need any more help

[istaheev]

I came accross this issue and got stuck on it as an inexperienced Rust user. From my understanding the piece of code mentioned in the issue should be equal to the next one where I substitute the constant's value directly into the pattern:

fn main() {
    match *b"xxxx" {
        *b"fooo" => {},
        _ => {}
    }
}

It fails with

<anon>:3:9: 3:10 error: unexpected token: `*`
<anon>:3         *b"fooo" => {},

which means (as far as I understand) that it is not enough to just add constant-to-pattern expansion but also modify match to support matching of dereferenced literals. Is it so or I missed something?

[eddyb]

@istaheev it is not, as literals in patterns are more limited than constant expressions.
@jakub- maybe it is time to have a serious solution for this and transform patterns into a structure specific to rustc::middle. const_eval::const_expr_to_pat is such a hack...

That said, I believe what @nrc is suggesting (turning *b"foo" into [b'f', b'o', b'o']) would "just" work, although it might not be as efficient as just matching against b"foo".

[barca]

I'm essentially done with the fix, should I continue to work on it/ push it if you are going to change the structure completely?

[eddyb]

@barca such restructuring may not happen for another couple months (or even years), so don't mind me and feel free to open a PR.

[nrc]

@barca: yes please!

[ghost]

@barca My apologies for ignoring your messages, the last month's been merciless for me time wise!

[code-ape]

I was wondering what the current state was for the issue. I'd be interested in contributing if more work needs to be done!

[barca]

@code-ape actually still working on the issue, although haven't had time to do it in the last few days since I was moving. I believe I am fairly close to solution, although am eternally optimistic regarding such issues.

[solson]

I've been looking through E-easy issues for something to do. It sounds like this was close to done, but it's been a few months now.

@barca Any updates?

@eddyb Is the restructuring you mentioned before any closer to happening (or already happened)?

[eddyb]

@tsion The MIR has landed (and it has its own pattern lowering), though I don't know if it supports this usecase correctly.
Also, nothing uses the MIR yet, that will happen in the following months.
cc @nikomatsakis

[nikomatsakis]

In general the treatment of constants in pattern checking is somewhat broken, actually (at least in my opinion). I've been meaning to write up something on this, will do so soon, but the TL;DR is that we always use structural equality, even if (e.g.) the Eq trait is not implemented, or is implemented differently.

That said, I imagine this use case ought to work, but there are many others that don't which I don't really think ought to work. I'm not sure I'd call this an E-easy bug, though, but I guess that's because I tend to think that we need to do more overhaul of our constant treatment (and especially in patterns).

[cramertj]

@eddyb @nikomatsakis Is this still E-easy or similar? I'd be interested in contributing if possible.

[eddyb]

@cramertj The transition to MIR-based constant evaluation should fix this.

[cramertj]

Ah, okay. Thanks.

[steveklabnik]

Triage: as far as I know, const evaluation is still undergoing an overhaul, I don't know if it's far enough along to work on this yet.