-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 6 pull requests #74084
Closed
Closed
Rollup of 6 pull requests #74084
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
This commit marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior. Signed-off-by: David Wood <david@davidtw.co>
to feature(rc_as_ptr) These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very confusing.
Previously, if there were a module in scope with the same name as the primitive, that would take precedence. Coupled with rust-lang#58699, this made it impossible to link to the primitive when that module was in scope. This approach could be extended so that `struct@foo` would no longer resolve to any type, etc. However, it could not be used for glob imports: ```rust pub mod foo { pub struct Bar; } pub enum Bar {} use foo::*; // This is expected to link to `inner::Bar`, but instead it will link to the enum. /// Link to [struct@Bar] pub struct MyDocs; ``` The reason for this is that this change does not affect the resolution algorithm of rustc_resolve at all. The only reason we could special-case primitives is because we have a list of all possible primitives ahead of time.
Add Integer::checked_{log,log2,log10} This implements `{log,log2,log10}` methods for all integer types. The implementation was provided by @substack for use in the stdlib. _Note: I'm not big on math, so this PR is a best effort written with limited knowledge. It's likely I'll be getting things wrong, but happy to learn and correct. Please bare with me._ ## Motivation Calculating the logarithm of a number is a generally useful operation. Currently the stdlib only provides implementations for floats, which means that if we want to calculate the logarithm for an integer we have to cast it to a float and then back to an int. > would be nice if there was an integer log2 instead of having to either use the f32 version or leading_zeros() which i have to verify the results of every time to be sure _— [@substack, 2020-03-08](https://twitter.com/substack/status/1236445105197727744)_ At higher numbers converting from an integer to a float we also risk overflows. This means that Rust currently only provides log operations for a limited set of integers. The process of doing log operations by converting between floats and integers is also prone to rounding errors. In the following example we're trying to calculate `base10` for an integer. We might try and calculate the `base2` for the values, and attempt [a base swap](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) to arrive at `base10`. However because we're performing intermediate rounding we arrive at the wrong result: ```rust // log10(900) = ~2.95 = 2 dbg!(900f32.log10() as u64); // log base change rule: logb(x) = logc(x) / logc(b) // log2(900) / log2(10) = 9/3 = 3 dbg!((900f32.log2() as u64) / (10f32.log2() as u64)); ``` _[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0)_ This is somewhat nuanced as a lot of the time it'll work well, but in real world code this could lead to some hard to track bugs. By providing correct log implementations directly on integers we can help prevent errors around this. ## Implementation notes I checked whether LLVM intrinsics existed before implementing this, and none exist yet. ~~Also I couldn't really find a better way to write the `ilog` function. One option would be to make it a private method on the number, but I didn't see any precedent for that. I also didn't know where to best place the tests, so I added them to the bottom of the file. Even though they might seem like quite a lot they take no time to execute.~~ ## References - [Log rules](https://www.rapidtables.com/math/algebra/Logarithm.html#log-rules) - [Rounding error playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6bd6c68b3539e400f9ca4fdc6fc2eed0) - [substack's tweet asking about integer log2 in the stdlib](https://twitter.com/substack/status/1236445105197727744) - [Integer Logarithm, A. Jaffer 2008](https://people.csail.mit.edu/jaffer/III/ilog.pdf)
…bank Audit hidden/short code suggestions Should fix rust-lang#73641. Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes. r? @estebank
…mp-generator-interior, r=matthewjasper mir: mark mir construction temporaries as internal Fixes rust-lang#73914. This PR marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior. r? @matthewjasper
Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr) These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very misleading, especially in a review context where the impl header may not be immediately visible. r? @RalfJung @bors rollup=always
…oli-obk Miri value validation: fix handling of uninit memory Fixes rust-lang/miri#1456 Fixes rust-lang/miri#1467 r? @oli-obk
Always resolve type@primitive as a primitive, not a module Previously, if there were a module in scope with the same name as the primitive, that would take precedence. Coupled with rust-lang#58699, this made it impossible to link to the primitive when that module was in scope. This approach could be extended so that `struct@foo` would no longer resolve to any type, etc. However, it could not be used for glob imports: ```rust pub mod foo { pub struct Bar; } pub enum Bar {} use foo::*; // This is expected to link to `inner::Bar`, but instead it will link to the enum. /// Link to [struct@Bar] pub struct MyDocs; ``` The reason for this is that this change does not affect the resolution algorithm of rustc_resolve at all. The only reason we could special-case primitives is because we have a list of all possible primitives ahead of time. Closes rust-lang#74063 r? @Manishearth
@bors r+ p=5 rollup=never |
📌 Commit 346a147 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Jul 6, 2020
@bors retry r+ |
💡 This pull request was already approved, no need to approve it again. |
📌 Commit 346a147 has been approved by |
⌛ Testing commit 346a147 with merge 7ba0056d5b438dfddd84b3f4e733d0f9082eac2a... |
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Jul 6, 2020
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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.
Successful merges:
Failed merges:
r? @ghost