Fix issue12118: Return value/use extra::test::black_box in benchmarks that are optimised to nothing #12212
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| x: 1, | ||
| y: 2, | ||
| z: 3, | ||
| }) | ||
| })); |
There was a problem hiding this comment.
This shouldn't need black_box because it can just return it from the closure (and bh.iter will black_box it)
There was a problem hiding this comment.
By "already fixed" I mean, there's no need to add the black_box call or change it in any way (the arena.alloc function is very fast): the lack of a trailing semicolon meant that it was returned by the closure.
|
Thanks! |
|
thank you both of you. |
| @@ -269,6 +269,7 @@ mod tests { | |||
| mod bench { | |||
|
|
|||
| use extra::test::BenchHarness; | |||
| use extra::test::black_box; | |||
|
Thank you |
| @@ -4464,13 +4465,14 @@ mod bench { | |||
| ptr::set_memory(vp, 0, 1024); | |||
| v.set_len(1024); | |||
| } | |||
| &v | |||
There was a problem hiding this comment.
You can just return v instead of &v.
(The test failures are because v is defined inside the closure, and so returning a reference would be creating a dangling pointer.)
|
Thank you. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 25, 2022
Fix a typo in the `inlayHints.renderColons` option description The description said the same thing twice: "trailing colons for parameter hints, and trailing colons for parameter hints". I'm assuming one of those is supposed to be about the leading colon for type hints. Also, I wasn't sure how to regenerate the generated file(s?) so I just manually updated them. Hopefully that isn't a problem. If how to do that is in the documentation somewhere I'd love to know.
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Feb 8, 2024
…s-fix, r=Jarcho Fix false positive in `redundant_type_annotations` lint This PR changes the `redundant_type_annotations` lint to allow slice type annotations (i.e., `&[u8]`) for byte string literals. It will still consider _array_ type annotations (i.e., `&[u8; 4]`) as redundant. The reasoning behind this is that the type of byte string literals is by default a reference to an array, but, by using a type annotation, you can force it to be a slice. For example: ```rust let a: &[u8; 4] = b"test"; let b: &[u8] = b"test"; ``` Now, the type annotation for `a` will still be linted (as it is still redundant), but the type annotation for `b` will not. Fixes rust-lang#12212. changelog: [`redundant_type_annotations`]: Fix false positive with byte string literals
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A try to fix #12118.
@huonw Could you please review that.