Use the least significant beat to determine if int/uint is even - #11568
Conversation
|
I'm curious, but have you verified that the generated code is actually better? I would expect LLVM to do proper inlining and figure everything out. Regardless, the documentation shouldn't change, just the implementation, but thanks for the patch! |
|
I didn't verify the generated code, I could check with Why shouldn't the documentation change? It's not verifying the number is divisible by 2 anymore :/ |
|
Maybe not the best test. TBH, not sure what the best test is. use std::num;
fn main() {
2u & 1 == 0;
2u.is_even();
} |
|
@flaper87 It still checks that the number is divisible by |
|
Interesting! Then, let me trash this patch! Thanks! 😄 |
|
I misunderstood @adridu59's comment. He was referring to the documentation. |
|
@flaper87 It looks like llvm eliminated all of your test since the results were unused. You probably need to print the output or something. |
|
This is the full output of the emit. http://pastebin.mozilla.org/4022063 And the test use std::num;
fn main() {
let a = 2u & 1 == 0;
let b = 2u.is_even();
println!("{}", a);
println!("{}", b);
} |
Still not convinced that this test is representative of the comparison we're looking for. |
|
Before: After: |
|
From the tests it appears they optimize to exactly the same thing, so LLVM is definitely doing its job. When running tests at O0, however, I imagine that and-ing with 1 is faster, so I'm gonna go ahead and r+ this. Thanks for the patch and the good investigation! |
This implementation should be a bit more optimal than calling `self.is_multiple_of(&2)`
ignore lower-camel-case words in `doc_markdown` This fixes rust-lang#11568 by ignoring camelCase words starting with a lower case letter. r? `@blyxyas` --- changelog: none
11686: feat: Enum variant field completion, enum variant / struct consistency r=Veykril a=m0rg-dev
This addresses several related inconsistencies:
- tuple structs use tab stops instead of placeholders
- tuple structs display in the completion menu as `Struct {…}` instead of `Struct(…)`
- enum variants don't receive field completions at all
- enum variants display differently from structs in the completion menu
Also, structs now display their type in the completion detail rather than the raw snippet text to be inserted.
As far as what's user-visible, that looks like this:
| | Menu | Completion | Detail |
|-|-|-|-|
| Record struct (old) | `Struct {…}` | `Struct { x: ${1:()}, y: ${2:()} }$0` | `Struct { x: ${1:()}, y: ${2:()} }$0` |
| Record struct (new) | `Struct {…}` | `Struct { x: ${1:()}, y: ${2:()} }$0` | `Struct { x: i32, y: i32 }` |
| Tuple struct (old) | `Struct {…}` | `Struct($1, $2)$0` | `Struct($1, $2)` |
| Tuple struct (new) | `Struct(…)` | `Struct(${1:()}, ${2:()})$0` | `Struct(i32, i32)` |
| Unit variant (old) | `Variant` | `Variant` | `()` |
| Unit variant (new) | `Variant` | `Variant$0` | `Variant` |
| Record variant (old) | `Variant` | `Variant` | `{x: i32, y: i32}` |
| Record variant (new) | `Variant {…}` | `Variant { x: ${1:()}, y: ${2:()} }$0` | `Variant { x: i32, y: i32 }` |
| Tuple variant (old) | `Variant(…)` | `Variant($0)` | `(i32, i32)` |
| Tuple variant (new) | `Variant(…)` | `Variant(${1:()}, ${2:()})$0` | `Variant(i32, i32)` |
Additionally, tuple variants no longer set `triggers_call_info` because it conflicts with placeholder generation, and tuple variants that require a qualified path should now use the qualified path.
Internally, this also lets us break the general "format an item with fields on it" code out into a shared module, so that means it'll be a lot easier to implement features like rust-lang#11568.
Co-authored-by: Morgan Thomas <corp@m0rg.dev>
11691: feat: Suggest union literals, suggest union fields within an empty union literal r=Veykril a=m0rg-dev
Adds a `Union {…}` completion in contexts where a union is expected, expanding to a choice of available fields (if snippets are supported):


Also, adds support for listing possible fields in an empty union literal.


Closes rust-lang#11568.
Co-authored-by: Morgan Thomas <corp@m0rg.dev>
This implementation should be a bit more optimal than calling
self.is_multiple_of(&2)