Closed
Conversation
-> `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 <phg@phi-gamma.net>
Signed-off-by: Philipp Gesang <phg@phi-gamma.net>
As suggested by @Centril. Signed-off-by: Philipp Gesang <phg@phi-gamma.net>
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`.
…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:  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.
Member
Author
|
@bors r+ p=8 rollup=never |
Collaborator
|
📌 Commit 76db75a has been approved by |
bors
added
the
S-waiting-on-bors
Collaborator
|
⌛ Testing commit 76db75a with merge 01c140bd6226311ae847a3ffdc067b6685396cad... |
Contributor
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Collaborator
|
💔 Test failed - checks-azure |
bors
added
S-waiting-on-review
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
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:
TooGenericerror in WF checking a proper error #68388 (MakeTooGenericerror in WF checking a proper error)Failed merges:
r? @ghost