-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Comments
Updating with what I believe the underlying bug is. |
@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
Updated report
It appears that iterators over vectors of 0-sized values are not currently valid:
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.
The text was updated successfully, but these errors were encountered: