- 07 7月, 2021 20 次提交
-
-
由 Yuki Okushi 提交于
Rename some Rust 2021 lints to better names Based on conversation in https://github.com/rust-lang/rust/issues/85894. Rename a bunch of Rust 2021 related lints: Lints that are officially renamed because they are already in beta or stable: * `disjoint_capture_migration` => `rust_2021_incompatible_closure_captures` * `or_patterns_back_compat` => `rust_2021_incompatible_or_patterns` * `non_fmt_panic` => `non_fmt_panics` Lints that are renamed but don't require any back -compat work since they aren't yet in stable: * `future_prelude_collision` => `rust_2021_prelude_collisions` * `reserved_prefix` => `rust_2021_token_prefixes` Lints that have been discussed but that I did not rename: * ~`non_fmt_panic` and `bare_trait_object`: is making this plural worth the headache we might cause users?~ * `array_into_iter`: I'm unsure of a good name and whether bothering users with a name change is worth it. r? `@nikomatsakis`
-
由 Yuki Okushi 提交于
Add Integer::log variants _This is another attempt at landing https://github.com/rust-lang/rust/pull/70835, which was approved by the libs team but failed on Android tests through Bors. The text copied here is from the original issue. The only change made so far is the addition of non-`checked_` variants of the log methods._ _Tracking issue: #70887_ --- 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)
-
由 bors 提交于
Refactor linker code This merges `LinkerInfo` into `CrateInfo` as there is no reason to keep them separate. `LinkerInfo::to_linker` is merged into `get_linker` as both have different logic for each linker type and `to_linker` is directly called after `get_linker`. Also contains a couple of small cleanups. See the individual commits for all changes.
-
由 bors 提交于
[msvc] Consistently show active variant and fix visualization for single variant enums Prior to this change, there were a few cases where inspecting an enum in either WinDbg or Visual Studio would not show the active variant name. After these changes, we now consistently show the active variant name as `[variant]` in the debugger. We also didn't handle single variant enums very well. That is now also resolved. Before: ![image](https://user-images.githubusercontent.com/831192/123480097-dc8b5f00-d5cf-11eb-93a8-9fc05a97029b.png) After: ![image](https://user-images.githubusercontent.com/831192/123479966-aa79fd00-d5cf-11eb-955e-9798616a8829.png) r? `@michaelwoerister`
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 Ryan Levick 提交于
-
由 bjorn3 提交于
-
由 bors 提交于
Force warnings even when can_emit_warnings == false Fixes an issue mentioned in #85512 with --cap-lints overriding --force-warnings. Fixes https://github.com/rust-lang/rust/issues/86751 r? `@ehuss`
-
由 bjorn3 提交于
-
由 bjorn3 提交于
-
由 bjorn3 提交于
-
- 06 7月, 2021 20 次提交
-
-
由 bjorn3 提交于
-
由 bjorn3 提交于
It is already part of CodegenResults
-
由 bjorn3 提交于
-
由 bors 提交于
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. In this PR we got rid of the per-target ABI denylists, and instead compute which ABIs are supported with a simple match based on, mostly, the `Target::arch` field. Among other things, this makes it impossible to forget to consider this problem (in either direction) and forces one to consider what the ABI support looks like when adding an ABI (rarely) rather than target (often), which should hopefully also reduce the cognitive load on both contributors as well as reviewers. Fixes #57182 Sponsored by: standard.ai --- ## Summary for teams One significant user-facing change after this PR is that there's now a future compat warning when building… * `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*; * `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*. Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another. The intention is that this warning becomes a hard error after some time.
-
由 Wesley Wiser 提交于
-
由 bjorn3 提交于
-
由 Ryan Levick 提交于
-
由 bors 提交于
Reland "Merge CrateDisambiguator into StableCrateId" Reverts https://github.com/rust-lang/rust/pull/85891 as this revert of #85804 made perf even worse. r? `@Mark-Simulacrum`
-
由 Simonas Kazlauskas 提交于
It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
-
由 bjorn3 提交于
-
由 bjorn3 提交于
-
由 bors 提交于
Store macro parent module in ExpnData. As a consequence, its value is hashed as part of the ExpnId's stable hash. Closes #85999
-
由 Camille GILLOT 提交于
-
由 bors 提交于
rustdoc: Replace `FakeDefId` with new `ItemId` type Follow up from #84707 `@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits, normal ids, and blanket impls instead of using `FakeDefId`s. This type is introduced by this PR. There are still some `FIXME`s left, because I was unsure what the best solution for them would be. Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no "fake" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too? Also, we need to represent the new item ids in the JSON backend somehow.
-
由 bors 提交于
Cleanup the computation of lint levels This now uses an `IndexVec` and a special root `LintStackIndex = 0` to encode command-line levels.
-
由 Wesley Wiser 提交于
-