-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add support for PowerPC64 on FreeBSD #57605
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
Conversation
manual impl was a workaround for #28229.
rustc: Fix regression where jemalloc isn't used In #56986 the linkage of jemalloc to the compiler was switched from the driver library to the rustc binary to ensure that only rustc itself uses jemalloc. In doing so, however, it turns out jemalloc wasn't actually linked in at all! None of the symbols were referenced so the static library wasn't used. This means that jemalloc wasn't pulled in at all. This commit performs a bit of a dance to reference jemalloc symbols, attempting to pull it in despite LLVM's optimizations. Closes #57115
use structured suggestion for method calls Furthermore, don't suggest calling the method if it is part of a place expression, as this is invalid syntax. I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice. The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas? r? @estebank
Since the values for the fcntl constants can vary from architecture to architecture, it is better to use the values defined in the libc crate instead of assigning literals in the flock code which would make the assumption that all architectures use the same values. Fixes #57007
flock: Use fcntl constants directly from libc crate on Unix targets Since the values for the fcntl constants can vary from architecture to architecture, it is better to use the values defined in the libc crate instead of assigning literals in the flock code which would make the assumption that all architectures use the same values. Fixes #57007
Make sure feature gate errors are recoverable (take 2) Continuation of 15cefe4. Turns out I missed the most important part - the main feature gate checking pass.
tests: Do not use `-Z parse-only`, continue compilation to test recovery Make tests closer to reality! The next step will be enabling `-Z continue-parse-after-error` by default and looking at the regressions. A few instances of `-Z parse-only` are kept when it's appropriate, see e.g `ui/impl-trait/impl-trait-plus-priority.rs`, which tests mostly semantically wrong code and would generate too much useless noise if allowed to continue.
Remove unused code
Save quite a few syscalls and avoiding pushing in a loop.
…crum slightly optimize compiletest test collection Save quite a few syscalls and avoiding pushing in a loop.
…kennytm Update compiler_builtins 0.1.2 -> 0.1.4 r? @alexcrichton
These can both rely on IEEE754 semantics to be made faster, by folding away the sign with an abs (left private for now), and then comparing to infinity, letting the NaN semantics of a direct float comparison handle NaN input properly. The `abs` bit-fiddling is simple (a single and), and so these new forms compile down to a few instructions, without branches, e.g. for f32: ```asm is_infinite: andps xmm0, xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF ucomiss xmm0, dword ptr [rip + .LCPI2_1] ; 0x7F80_0000 setae al ret is_finite: andps xmm0, xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF movss xmm1, dword ptr [rip + .LCPI1_1] ; 0x7F80_0000 ucomiss xmm1, xmm0 seta al ret ``` When used in loops/repeatedly, they get even better: the memory operations (loading the mask 0x7FFFFFFF for abs, and infinity 0x7F80_0000) are likely to be hoisted out of the individual calls, to be shared, and the `seta`/`setae` are likely to be collapsed into conditional jumps or moves (or similar). The old `is_infinite` did two comparisons, and the old `is_finite` did three (with a branch), and both of them had to check the flags after every one of those comparison. These functions have had that old implementation since they were added in 6284190 7 years ago. Benchmark (`abs` is the new form, `std` is the old): ``` test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10) test f32_is_finite_std ... bench: 118 ns/iter (+/- 5) test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1) test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6) test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12) test f64_is_finite_std ... bench: 128 ns/iter (+/- 25) test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5) test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23) ``` ```rust #![feature(test)] extern crate test; use std::{f32, f64}; use test::Bencher; const VALUES_F32: &[f32] = &[0.910, 0.135, 0.735, -0.874, 0.518, 0.150, -0.527, -0.418, 0.449, -0.158, -0.064, -0.144, -0.948, -0.103, 0.225, -0.104, -0.795, 0.435, 0.860, 0.027, 0.625, -0.848, -0.454, 0.359, -0.930, 0.067, 0.642, 0.976, -0.682, -0.035, 0.750, 0.005, -0.825, 0.731, -0.850, -0.740, -0.118, -0.972, 0.888, -0.958, 0.086, 0.237, -0.580, 0.488, 0.028, -0.552, 0.302, 0.058, -0.229, -0.166, -0.248, -0.430, 0.789, -0.122, 0.120, -0.934, -0.911, -0.976, 0.882, -0.410, 0.311, -0.611, -0.758, 0.786, -0.711, 0.378, 0.803, -0.068, 0.932, 0.483, 0.085, 0.247, -0.128, -0.839, -0.737, -0.605, 0.637, -0.230, -0.502, 0.231, -0.694, -0.400, -0.441, 0.142, 0.174, 0.681, -0.763, -0.608, 0.848, -0.550, 0.883, -0.212, 0.876, 0.186, -0.909, 0.401, -0.533, -0.961, 0.539, -0.298, -0.448, 0.223, -0.307, -0.594, 0.629, -0.534, 0.959, 0.349, -0.926, -0.523, -0.895, -0.157, -0.074, -0.060, 0.513, -0.647, -0.649, 0.428, 0.401, 0.391, 0.426, 0.700, 0.880, -0.101, 0.862, 0.493, 0.819, -0.597]; #[bench] fn f32_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite())); } #[bench] fn f32_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY)); } #[bench] fn f32_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite())); } #[bench] fn f32_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY)); } const VALUES_F64: &[f64] = &[0.910, 0.135, 0.735, -0.874, 0.518, 0.150, -0.527, -0.418, 0.449, -0.158, -0.064, -0.144, -0.948, -0.103, 0.225, -0.104, -0.795, 0.435, 0.860, 0.027, 0.625, -0.848, -0.454, 0.359, -0.930, 0.067, 0.642, 0.976, -0.682, -0.035, 0.750, 0.005, -0.825, 0.731, -0.850, -0.740, -0.118, -0.972, 0.888, -0.958, 0.086, 0.237, -0.580, 0.488, 0.028, -0.552, 0.302, 0.058, -0.229, -0.166, -0.248, -0.430, 0.789, -0.122, 0.120, -0.934, -0.911, -0.976, 0.882, -0.410, 0.311, -0.611, -0.758, 0.786, -0.711, 0.378, 0.803, -0.068, 0.932, 0.483, 0.085, 0.247, -0.128, -0.839, -0.737, -0.605, 0.637, -0.230, -0.502, 0.231, -0.694, -0.400, -0.441, 0.142, 0.174, 0.681, -0.763, -0.608, 0.848, -0.550, 0.883, -0.212, 0.876, 0.186, -0.909, 0.401, -0.533, -0.961, 0.539, -0.298, -0.448, 0.223, -0.307, -0.594, 0.629, -0.534, 0.959, 0.349, -0.926, -0.523, -0.895, -0.157, -0.074, -0.060, 0.513, -0.647, -0.649, 0.428, 0.401, 0.391, 0.426, 0.700, 0.880, -0.101, 0.862, 0.493, 0.819, -0.597]; #[bench] fn f64_is_infinite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite())); } #[bench] fn f64_is_infinite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY)); } #[bench] fn f64_is_finite_std(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite())); } #[bench] fn f64_is_finite_abs(b: &mut Bencher) { b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY)); } ```
Bump stage0 Updates stage 0 From: rustc 1.32.0-beta.2 (a01e476 2018-12-08) To: rustc 1.32.0-beta.11 (e64fee6 2019-01-04) Intended to pull in #57292 which will fix #57142. The following is a list of PRs this also pulls in in case anyone is interested in seeing the changes: #56930 #56961 #57236 #57305
Use fonts from the Roman 2.007 and Italic 1.007 version at: https://github.com/adobe-fonts/source-serif-pro/releases/tag/2.007R-ro%2F1.007R-it The following files are used from the distribution: * WOFF/TTF/SourceSerifPro-Regular.ttf.woff * WOFF/TTF/SourceSerifPro-Bold.ttf.woff * WOFF/TTF/SourceSerifPro-It.ttf.woff These replace the older Source Serif Pro regular and bold fonts, and the Heuristica italic font.
NLL: Fix bug in associated constant type annotations. Fixes #57280. This PR reverses the variance used when relating types from the type annotation of an associated constant - this matches the behaviour of the lexical borrow checker and fixes a bug whereby matching a `&'a str` against a `&'static str` would produce an error. r? @nikomatsakis
Tweak output of type mismatch between "then" and `else` `if` arms ``` error[E0308]: if and else have incompatible types --> $DIR/if-else-type-mismatch.rs:5:9 | LL | let _ = if true { | _____________- LL | | 42i32 | | ----- expected because of this LL | | } else { LL | | 42u32 | | ^^^^^ expected i32, found u32 LL | | }; | |_____- if and else have incompatible types | = note: expected type `i32` found type `u32` error[E0308]: if and else have incompatible types --> file.rs:2:38 | LL | let _ = if false { 3u8; } else { 3u8 }; | ---- ^^^ expected (), found u8 | | | | | help: consider removing this semicolon | expected because of this | = note: expected type `()` found type `u8` error[E0308]: if and else have incompatible types --> file.rs:3:37 | LL | let _ = if false { 3u8 } else { 3u8; }; | --- ^^^- | | | | | | | help: consider removing this semicolon | | expected u8, found () | expected because of this | = note: expected type `u8` found type `()` error[E0308]: if and else have incompatible types --> file.rs:4:37 | LL | let _ = if false { 3i8 } else { 3u8 }; | --- ^^^ expected i8, found u8 | | | expected because of this | = note: expected type `i8` found type `u8` ``` Fix #57348.
Use structured suggestions for nonstandard style lints This PR modifies the lints in the nonstandard_style group to use structured suggestions. Note that there's a bit of tricky span calculation going on for the `crate_name` attribute. It also simplifies the code a bit: I don't think the "fallback" suggestions for these lints can actually be triggered. Fixes #48103. Fixes #52414.
Stabilize core::convert::identity r? @SimonSapin fixes #53500 This is waiting for FCP to complete but in the interim it would be good to review.
Parallelize and optimize parts of HIR map creation r? @michaelwoerister
MetadataOnlyCodegenBackend: run the collector only once Use the `collect_and_partition_mono_items` query to avoid calling the collector directly twice. Fixes #57406.
…shtriplett,Centril Stabilize cfg_target_vendor This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates. This functionality was added back in 2015 in #28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in #24777, never behind a feature_gate, and insta-stable at 1.1.0. The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs). Closes #29718
clarify resolve typo suggestion Include the kind of the binding that we're suggesting, and use a structured suggestion. Fixes #53445.
Rollup of 6 pull requests Successful merges: - #57232 (Parallelize and optimize parts of HIR map creation) - #57418 (MetadataOnlyCodegenBackend: run the collector only once) - #57465 (Stabilize cfg_target_vendor) - #57477 (clarify resolve typo suggestion) - #57556 (privacy: Fix private-in-public check for existential types) - #57584 (Remove the `connect_timeout_unroutable` test.) Failed merges: r? @ghost
Update cargo 13 commits in 34320d212dca8cd27d06ce93c16c6151f46fcf2e..2b4a5f1f0bb6e13759e88ea9512527b0beba154f 2019-01-03 19:12:38 +0000 to 2019-01-12 04:13:12 +0000 - Add test for publish with [patch] + cleanup. (rust-lang/cargo#6544) - Fix clippy warning (rust-lang/cargo#6546) - Revert "Workaround by using yesterday's nightly" (rust-lang/cargo#6540) - Adding feature-flags to `cargo publish` and `cargo package` (rust-lang/cargo#6453) - Fix the Travis CI badge (rust-lang/cargo#6530) - Add helpful text for Windows exceptions like Unix (rust-lang/cargo#6532) - Report fix bugs to Rust instead of Cargo (rust-lang/cargo#6531) - --{example,bin,bench,test} with no argument now lists all available targets (rust-lang/cargo#6505) - Rebuild on mid build file modification (rust-lang/cargo#6484) - Derive Clone for TomlDependency (rust-lang/cargo#6527) - publish: rework the crates.io detection logic. (rust-lang/cargo#6525) - avoid duplicates in ignore files (rust-lang/cargo#6521) - Rustflags in metadata (rust-lang/cargo#6503) r? @alexcrichton
Some changes occurred in HTML/CSS. |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
This should target |
my bad! Should've been against master. Please change. tks! |
I don't think this can be changed after the PR is opened. Try opening a new one with the right branches. |
It can. You need to |
@estebank I think that does something different - the problem here is that the PRs target branch was set to Oh and apparently the source branch is set to this repos |
You can change the target branch, but for some reason here I can't change it to master, the list of commits is different to what I'd expect. Now that I think about it, it might not be letting me to select master because it's already merged into this PR. |
It's not letting me select master. I'll close the PR and resubmit. |
These are changes to add support for powerpc64 on FreeBSD.
patch-ppc64.txt