Skip to content
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

Cannot use tiny_vec! with one non-constant element #200

Open
TonalidadeHidrica opened this issue Sep 11, 2024 · 2 comments
Open

Cannot use tiny_vec! with one non-constant element #200

TonalidadeHidrica opened this issue Sep 11, 2024 · 2 comments

Comments

@TonalidadeHidrica
Copy link

TonalidadeHidrica commented Sep 11, 2024

The following code tries to create a TinyVec with a single element, but it fails at the tiny_vec!. (playground)

use tinyvec::{TinyVec, tiny_vec};

fn main() {
    let a = 1;
    let _: TinyVec<[u8; 4]> = tiny_vec![a];
}
   Compiling playground v0.0.1 (/playground)
error[E0435]: attempt to use a non-constant value in a constant
 --> src/main.rs:5:41
  |
5 |     let _: TinyVec<[u8; 4]> = tiny_vec![a];
  |                                         ^ non-constant value
  |
help: consider using `const` instead of `let`
  |
4 |     const a: /* Type */ = 1;
  |     ~~~~~  ++++++++++++

For more information about this error, try `rustc --explain E0435`.
error: could not compile `playground` (bin "playground") due to 1 previous error

This does not seem to happen for zero or two elements, or when the type is declared on its left (tiny_vec![ [u8; 4] => a ]).

@pr2502
Copy link

pr2502 commented Sep 11, 2024

the problem appears to be with the pattern here https://github.com/Lokathor/tinyvec/blob/main/src/tinyvec.rs#L56-L61 getting a priority over the next branch. for a quick an dirty fix you can wrap a in braces to disambiguate it as an expression and not a type.

use tinyvec::{TinyVec, tiny_vec};

fn main() {
    let a = 1;
    let _: TinyVec<[u8; 4]> = tiny_vec![{a}];
}

@Lokathor
Copy link
Owner

We've had occasional problems with this macro before, and unfortunately I think the answer is that it just "is what it is" at this point. If we try to reorder the macro arms then it probably breaks someone.

We should probably document this on the macro at least, even if we can't fix it fully.

@Lokathor Lokathor self-assigned this Sep 11, 2024
@Lokathor Lokathor removed their assignment Jan 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants