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 https://github.com/rust-lang/rust/issues/66962.
r? @eddyb
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 https://github.com/rust-lang/rust/pull/67110.
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/))
[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 #64191
This change adds the x86_64-fuchsia and aarch64-fuchsia LLVM targets to
those allowed to invoke -Zsanitizer. Currently, the only overlap between
compiler_rt sanitizers supported by both rustc and Fuchsia is ASan.
Fix CI for embedded ARM targets
Closes https://github.com/rust-lang/rust/issues/67018
It would be better to move the `thumb-none-cortex-m` test into the `cargotest` suite, but it doesn't seem to support cross-compilation.
typeck: simplify the handling of `diverges`
Some drive-by cleanup while working on `hir::ExprKind::Let`.
Ostensibly, this has some perf benefits due to reduced allocation and whatnot as well.
r? @eddyb
Update cargo, books
## cargo
9 commits in ad3dbe10e1e654fb1f032a5dd9481d7cbaa00d65..f6449ba236db31995255ac5e4cad4ab88296a7c6
2020-01-13 21:37:15 +0000 to 2020-01-21 16:15:39 +0000
- Fix wrong directories in host_libdir. (rust-lang/cargo#7798)
- Update humantime requirement from 1.2.0 to 2.0.0 (rust-lang/cargo#7815)
- Fix doc_target test which no longer works on stable/beta. (rust-lang/cargo#7817)
- Fix some erroneous em-dashes in man pages. (rust-lang/cargo#7814)
- fix some clippy warnings (rust-lang/cargo#7808)
- Don't assume iowait always increases on Linux (rust-lang/cargo#7803)
- Add and update some doc comments. (rust-lang/cargo#7800)
- Consistently use em-dash in environment documentation page. (rust-lang/cargo#7799)
- Load credentials only when needed (rust-lang/cargo#7774)
## reference
3 commits in e1157538e86d83df0cf95d5e33bd943f80d0248f..11e893fc1357bc688418ddf1087c2b7aa25d154d
2019-12-22 13:13:14 +0100 to 2020-01-18 21:24:08 +0100
- Small improvements to types/pointer.md (rust-lang-nursery/reference#726)
- repr(transparent): mention align=1 requirement (rust-lang-nursery/reference#737)
- Elaborate on how to use an extern static correctly (rust-lang-nursery/reference#736)
## book
4 commits in 5c5cfd2e94cd42632798d9bd3d1116133e128ac9..87dd6843678575f8dda962f239d14ef4be14b352
2019-12-16 09:27:21 -0600 to 2020-01-20 15:20:40 -0500
- Fix listing numbers (rust-lang/book#2227)
- Move `async` and `await` keywords to 'Currently in Use' (rust-lang/book#2140)
- More cleanup - remove unneeded files (rust-lang/book#2213)
- Small cleanups extracted from the bigger pr i'm working on (rust-lang/book#2212)
## rust-by-example
1 commits in 1d59403cb5269c190cc52a95584ecc280345495a..1c2bd024d13f8011307e13386cf1fea2180352b5
2019-12-27 08:27:05 -0300 to 2020-01-20 12:18:36 -0300
- CamelCase -> UpperCamelCase (rust-lang/rust-by-example#1302)
## embedded-book
1 commits in 9493b7d4dc97eda439bd8780f05ad7b234cd1cd7..4d78994915af1bde9a95c04a8c27d8dca066232a
2019-12-27 20:05:00 +0000 to 2020-01-14 08:25:25 +0000
- Update .gitattributes (rust-embedded/book#221)
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`.
Options IP_MULTICAST_TTL and IP_MULTICAST_LOOP are 1 byte on BSD
Options IP_MULTICAST_TTL and IP_MULTICAST_LOOP are 1 byte on BSD and Solaris
See ip(4P) man page:
IP_MULTICAST_TTL Time to live for multicast datagrams. This option
takes an unsigned character as an argument. Its
value is the TTL that IP uses on outgoing multi-
cast datagrams. The default is 1.
IP_MULTICAST_LOOP Loopback for multicast datagrams. Normally multi-
cast datagrams are delivered to members on the
sending host (or sending zone). Setting the
unsigned character argument to 0 causes the oppo-
site behavior, meaning that when multiple zones
are present, the datagrams are delivered to all
zones except the sending zone.
https://docs.oracle.com/cd/E88353_01/html/E37851/ip-4p.htmlhttps://man.openbsd.org/ip.4
Implement `?const` opt-out for trait bounds
For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment.
Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR.
After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering.
cc #67794
r? @oli-obk
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>
