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

ty_fixed_length_vec's length const-expr not eval'ed consistently (vs other const-exprs) #10122

Closed
pnkfelix opened this issue Oct 28, 2013 · 3 comments

Comments

@pnkfelix
Copy link
Member

From: https://gist.github.com/pnkfelix/7198893

Part of #5551 metabug.

First, an illustration that field-dereference can be used in some const expressions. This compiles and runs:

struct foo { x: int, y: int }
static A : foo = foo { x: 3, y: 4 };
static B : int = A.x;

fn main() {
println!("{:?}", B);

But, even though the above compiles and runs, a use of B as the length of a fixed length vec fails to compile.

struct foo { x: int, y: int }
static A : foo = foo { x: 3, y: 4 };

#[cfg(field_proj)]
static B : int = A.x;

#[cfg(inline_val)]
static B : int = 3;

fn main() {
let v : [int, ..B] = [5, 6, 7];
println!("{:?}", v);
}
% ./x86_64-apple-darwin/stage0/bin/rustc --cfg inline_val /tmp/f.rs && /tmp/f
warning: no debug symbols in executable (-arch x86_64)
[5, 6, 7]
% ./x86_64-apple-darwin/stage0/bin/rustc --cfg field_proj /tmp/f.rs && /tmp/f
/tmp/f.rs:11:12: 11:22 error: expected constant expr for vector length: Unsupported constant expr
/tmp/f.rs:11 let v : [int, ..B] = [5, 6, 7];
^~~~~~~~~~
task '<unnamed>' failed at 'explicit failure', /Users/rustbuild/src/rust-buildbot/slave/snap3-mac/build/src/libsyntax/diagnostic.rs:75
task '<unnamed>' failed at 'explicit failure', /Users/rustbuild/src/rust-buildbot/slave/snap3-mac/build/src/librustc/rustc.rs:395
% 
@pnkfelix
Copy link
Member Author

See also some relevant discussion from #rust-internals: https://botbot.me/mozilla/rust-internals/msg/7305244/

@steveklabnik
Copy link
Member

Triage: updated code:

struct foo { x: i32, y: i32 }
static A : foo = foo { x: 3, y: 4 };

#[cfg(field_proj)]
static B : i32 = A.x;

#[cfg(inline_val)]
static B : i32 = 3;

fn main() {
    let v : [i32; B] = [5, 6, 7];
    println!("{:?}", v);
}

updated error:

hello.rs:11:19: 11:20 error: unresolved name `B`
hello.rs:11     let v : [i32; B] = [5, 6, 7];
                              ^

@pnkfelix
Copy link
Member Author

@steveklabnik were you passing in the necessary --cfg flags to expose the distinct cases here?

Plus I think this bug dates from before we had the static/const distinction; one needs to use const now.

So I think the appropriate update looks more like this:

struct foo { x: usize, y: usize }
const A : foo = foo { x: 3, y: 4 };

#[cfg(field_proj)]
const B : usize = A.x;

#[cfg(inline_val)]
const B : usize = 3;

fn main() {
    let v : [i32; B] = [5, 6, 7];
    println!("{:?}", v);
}

which, huzzah, works now for both the --cfg field_proj and --cfg inline_val configurations! So I'm going to close this bug.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 12, 2023
[`drop_ref`]: don't lint idiomatic in match arm

fixes rust-lang#10122

As established in issue rust-lang#9482, it is idiomatic to use a single `drop()` expression in a match arm to achieve a side-effect of a function while discarding its output. This should also apply to cases where the function returns a reference.

The change to the lint's code was less than 1 line, because all the heavy lifting was done in PR rust-lang#9491.

---

changelog: FP: [`drop_ref`]: No longer lints idiomatic expression in `match` arms
[rust-lang#10142](rust-lang/rust-clippy#10142)
<!-- changelog_checked -->
lnicola pushed a commit to lnicola/rust that referenced this issue Jun 19, 2023
…r=HKalbasi

Infer return type for async function in `generate_function`

Part of rust-lang#10122

In `generate_function` assist, when we infer the return type of async function we're generating, we should retrieve the type of parent await expression rather than the call expression itself.
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

2 participants