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

Vec<()> does not iterate correctly #13467

Closed
andrewd18 opened this issue Apr 11, 2014 · 2 comments · Fixed by #13468
Closed

Vec<()> does not iterate correctly #13467

andrewd18 opened this issue Apr 11, 2014 · 2 comments · Fixed by #13468

Comments

@andrewd18
Copy link

Updated report

It appears that iterators over vectors of 0-sized values are not currently valid:

fn main() { 
    assert!(vec!(()).iter().len() == 1); 
}

Original report

rust 0.10 for loop ignores trait methods on unit-like structs

Using Rust 0.10 on Windows. If I call a for loop on structs that implement a trait method, structs with attributes have their methods called. Unit-like structs do not. As far as I can tell, the for loop never iterates despite there being an object to iterate upon.

Calling the methods in other contexts (directly, or in a vec cast to trait) works as expected.

trait GetAttribute {
    fn get_attribute(&self) -> int;
}

struct VariableAttribute {
    attribute: int
}
impl GetAttribute for VariableAttribute {
    fn get_attribute(&self) -> int {
        self.attribute
    }
}

struct UnitLike;
impl GetAttribute for UnitLike {
    fn get_attribute(&self) -> int {
        4
    }
}

fn main() {
    let va = VariableAttribute{attribute: 1};
    let ul = UnitLike;

    // Calling the method on each object individually works.
    let mut total = 0;
    total += va.get_attribute();
    total += ul.get_attribute();

    assert_eq!(total, 5);


    // Placing each object in a vector cast to the trait,
    // then calling the method on each object works.
    let cast_vec = vec!(&va as &GetAttribute, &ul as &GetAttribute);
    let mut cast_vec_total = 0;
    for object in cast_vec.iter() { cast_vec_total += object.get_attribute() }

    assert_eq!(cast_vec_total, 5);

    // However, placing each object in their own, non-cast vectors,
    // then calling the method on each object fails
    let va_vec = vec!(va);
    let sa_vec = vec!(ul);

    let mut noncast_vec_total = 0;
    for object in va_vec.iter() { noncast_vec_total += object.get_attribute() }
    for object in sa_vec.iter() { noncast_vec_total += object.get_attribute() }

    // The sa vector does have a length...
    assert_eq!(1, sa_vec.len());

    // ... But without a variable in the struct, the for loop doesn't even care.
    for object in sa_vec.iter() { println!("I never even get called. :("); }

    // And thus we get 1.
    assert_eq!(noncast_vec_total, 5);
}
@alexcrichton alexcrichton changed the title rust 0.10 for loop ignores trait methods on unit-like structs Vec<()> does not iterate correctly Apr 11, 2014
@alexcrichton
Copy link
Member

Updating with what I believe the underlying bug is.

@andrewd18
Copy link
Author

@alexcrichton Thanks! Apologies for the unclear title and verbosity.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 11, 2014
Previously, all slices derived from a vector whose values were of size 0 had a
null pointer as the 'data' pointer on the slice. This caused first pointer to be
yielded during iteration to always be the null pointer. Due to the null pointer
optimization, this meant that the first return value was None, instead of
Some(&T).

This commit changes slice construction from a Vec instance to use a base pointer
of 1 if the values have zero size. This means that the iterator will never
return null, and the iteration will proceed appropriately.

Closes rust-lang#13467
bors added a commit that referenced this issue Apr 13, 2014
Previously, all slices derived from a vector whose values were of size 0 had a
null pointer as the 'data' pointer on the slice. This caused first pointer to be
yielded during iteration to always be the null pointer. Due to the null pointer
optimization, this meant that the first return value was None, instead of
Some(&T).

This commit changes slice construction from a Vec instance to use a base pointer
of 1 if the values have zero size. This means that the iterator will never
return null, and the iteration will proceed appropriately.

Closes #13467
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
…osure, r=Veykril

Convert nested function to closure assist

Continuation of / closes rust-lang#13467.
Resolves rust-lang#13230.

r? `@Veykril`
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 10, 2024
Don't warn on proc macro generated code in `needless_return`

Fixes rust-lang#13458
Fixes rust-lang#13457
Fixes rust-lang#13467
Fixes rust-lang#13479
Fixes rust-lang#13481
Fixes rust-lang#13526
Fixes rust-lang#13486

The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does*  fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.

The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.

"Hide whitespace" helps a bit for reviewing the proc macro detection change

changelog: none
rust-cloud-vms bot pushed a commit to liwagu/rust that referenced this issue Oct 10, 2024
Don't warn on proc macro generated code in `needless_return`

Fixes rust-lang#13458
Fixes rust-lang#13457
Fixes rust-lang#13467
Fixes rust-lang#13479
Fixes rust-lang#13481
Fixes rust-lang#13526
Fixes rust-lang#13486

The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does*  fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.

The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.

"Hide whitespace" helps a bit for reviewing the proc macro detection change

changelog: none
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 18, 2024
Don't warn on proc macro generated code in `needless_return`

Fixes rust-lang#13458
Fixes rust-lang#13457
Fixes rust-lang#13467
Fixes rust-lang#13479
Fixes rust-lang#13481
Fixes rust-lang#13526
Fixes rust-lang#13486

The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does*  fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.

The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.

"Hide whitespace" helps a bit for reviewing the proc macro detection change

changelog: none
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 18, 2024
Don't warn on proc macro generated code in `needless_return`

Fixes rust-lang#13458
Fixes rust-lang#13457
Fixes rust-lang#13467
Fixes rust-lang#13479
Fixes rust-lang#13481
Fixes rust-lang#13526
Fixes rust-lang#13486

The fix is unfortunately a little more convoluted than just simply adding a `is_from_proc_macro`. That check *does*  fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g. `return format!(..)`.

The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for `return format!(..)` because we would have the patterns `("return", <something inside of the format macro>)`, which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context.

"Hide whitespace" helps a bit for reviewing the proc macro detection change

changelog: none
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

Successfully merging a pull request may close this issue.

2 participants