-
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 10 pull requests #68474
Merged
Merged
Rollup of 10 pull requests #68474
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
-> `rustc --target armv7-none-eabi` will work also build rust-std (rustup) components for them -> `rustup target add armv7-none-eabi` will work
…D 13.0-CURRENT i386 rust-nightly has been failing to link since 2019-12-10 with variations of ``` = note: ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o) >>> referenced by std.4xivr03c-cgu.14 >>> std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h1c78ed6e734a2bfc (.llvm.10122419023709863394)) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o) >>> referenced by std.4xivr03c-cgu.14 >>> std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(std::io::util::copy::h9115f048f2203467) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib clang-cpp: error: linker command failed with exit code 1 (use -v to see invocation) error: aborting due to previous error error: could not compile `rustc_macros`. ``` Full log: http://beefy17.nyi.freebsd.org/data/head-i386-default/p523508_s356869/logs/rust-nightly-1.42.0.20200118.log AFAICT it stopped building after bumping compiler_builtins to 0.1.22 in rust-lang#67110.
`TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.
it needs some upstream changes in the build script of the compiler-builtins crate
The diagnostic for diagnostic for methods and trait provided methods would only show the empty string: error[E0277]: the `?` operator can only be used in that returns `Result` or `Option` (or another type that implements `std::ops::Try`) Handle the missing cases so it reads ``a method'' / ``an async method'' / ``a trait method'' respectively. Signed-off-by: Philipp Gesang <[email protected]>
Signed-off-by: Philipp Gesang <[email protected]>
As suggested by @Centril. Signed-off-by: Philipp Gesang <[email protected]>
We already have ownership of the base path, so no need to clone it (within Path::with_extension).
Clarify where the clippy used in `./x.py clippy` is coming from. It uses whatever clippy binary was installed via rustup, cargo-install or otherwise and does NOT use the binary generated by `./x.py build src/tools/clippy`.
Adds a compiler option to allow rustc compile a crate without linking. With this flag, rustc serializes codegen_results into a .rlink file.
[experiment] Add `-Z no-link` flag Adds a compiler option to allow rustc compile a crate without linking. With this flag, `rustc` serializes codegen_results into a `.rlink` file. Part of Issue rust-lang#64191
…crichton add bare metal ARM Cortex-A targets to rustc -> `rustc --target armv7a-none-eabi` will work also build rust-std (rustup) components for them -> `rustup target add armv7a-none-eabi` will work this completes our bare-metal support of ARMv7 cores on stable Rust (by 1.42 or 1.43) (these target specifications have been tested on a real (no emulation / QEMU) [Cortex-A7 core](https://github.com/iqlusioninc/usbarmory.rs/))
…ichton Unbreak linking with lld 9 on FreeBSD 13.0-CURRENT i386 Add -Wl,-znotext to default linker flags to link with lld 9 on FreeBSD 13.0-CURRENT i386 where rust-nightly has been failing to link since 2019-12-10 with variations of ``` = note: ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o) >>> referenced by std.4xivr03c-cgu.14 >>> std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h1c78ed6e734a2bfc (.llvm.10122419023709863394)) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o) >>> referenced by std.4xivr03c-cgu.14 >>> std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(std::io::util::copy::h9115f048f2203467) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib clang-cpp: error: linker command failed with exit code 1 (use -v to see invocation) error: aborting due to previous error error: could not compile `rustc_macros`. ``` Full log: http://beefy17.nyi.freebsd.org/data/head-i386-default/p523508_s356869/logs/rust-nightly-1.42.0.20200118.log AFAICT it stopped building after bumping compiler_builtins to 0.1.22 in rust-lang#67110.
Make `TooGeneric` error in WF checking a proper error `TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing. Fixes rust-lang#66962. r? @eddyb
Micro-optimize OutputFilenames For example, its methods consume 6% of time during debug-compiling a `warp` example: ![Screenshot (debug-compiling a `warp` example)](https://user-images.githubusercontent.com/7091080/72780288-d74f1580-3c61-11ea-953b-34e59ca682f9.png) This PR optimize them a bit by using `PathBuf::set_extension` instead of `Path::with_extension`, to avoid cloning `PathBuf` excessively.
Export weak symbols used by MemorySanitizer Export weak symbols defined by MemorySanitizer instrumentation, which are used to implement `-Zsanitizer-memory-track-origins` and `-Zsanitizer-recover=memory`. Previously, when using fat LTO, they would internalized and eliminated. Fixes rust-lang#68367.
Fix try-op diagnostic in E0277 for methods For methods the try-op diagnostic displays the empty string where it has more descriptive strings like “a function” otherwise: error[E0277]: the `?` operator can only be used in that returns `Result` or `Option` (or another type that implements `std::ops::Try`) ^^ | | ^^ cannot use the `?` operator in that returns `()` ^^ I’m seeing this on nightly (rustc 1.42.0-nightly (b5a3341 2020-01-20)) and [on the playpen](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0e7ce7792c2aceb8056941710d539124). The changeset add strings for impl methods and trait provided methods and test cases for the option type.
…lacrum bootstrap: update clippy subcmd decription Clarify where the clippy used in `./x.py clippy` is coming from. It uses whatever clippy binary was installed via rustup, cargo-install or otherwise and does NOT use the binary generated by `./x.py build src/tools/clippy`.
…ulacrum pprust: use as_deref Some drive-by cleanup.
librustc_mir: don't allocate vectors where slices will do.
@bors r+ p=10 rollup=never |
📌 Commit bfac73c 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
Jan 23, 2020
bors
added a commit
that referenced
this pull request
Jan 23, 2020
Rollup of 10 pull requests Successful merges: - #67195 ([experiment] Add `-Z no-link` flag) - #68253 (add bare metal ARM Cortex-A targets to rustc) - #68361 (Unbreak linking with lld 9 on FreeBSD 13.0-CURRENT i386) - #68388 (Make `TooGeneric` error in WF checking a proper error) - #68409 (Micro-optimize OutputFilenames) - #68410 (Export weak symbols used by MemorySanitizer) - #68425 (Fix try-op diagnostic in E0277 for methods) - #68440 (bootstrap: update clippy subcmd decription) - #68441 (pprust: use as_deref) - #68462 (librustc_mir: don't allocate vectors where slices will do.) Failed merges: r? @ghost
☀️ Test successful - checks-azure |
This was referenced Jan 23, 2020
Merged
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merged-by-bors
This PR was explicitly merged by bors.
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
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:
-Z no-link
flag #67195 ([experiment] Add-Z no-link
flag)TooGeneric
error in WF checking a proper error #68388 (MakeTooGeneric
error in WF checking a proper error)Failed merges:
r? @ghost