| Age | Commit message (Collapse) | Author | Lines |
|---|
|
[beta] Backport book changes for rustup
|
|
|
|
|
|
Fixes #35653
cc https://github.com/rust-lang/rust-www/pull/621
|
|
[beta] Work around a borrow surviving too long (fixes #37686)
|
|
|
|
[beta] backports and bump
|
|
|
|
Fixes #38002.
|
|
|
|
|
|
This is an annoying gotcha with the projection cache's handling of
nested obligations.
Nested projection obligations enter the issue in this case:
```
DEBUG:rustc::traits::project: AssociatedTypeNormalizer: depth=3
normalized
<std::iter::Map<std::ops::Range<i32>,
[closure@not-a-recursion-error.rs:5:30: 5:53]> as
std::iter::IntoIterator>::Item to _#7t with 12 add'l obligations
```
Here the normalization result is the result of the nested impl
`<[closure@not-a-recursion-error.rs:5:30: 5:53] as FnMut(i32)>::Output`,
which is an additional obligation that is a part of "add'l obligations".
By itself, this is proper behaviour - the additional obligation is
returned, and the RFC 447 rules ensure that it is processed before the
output `#_7t` is used in any way.
However, the projection cache breaks this - it caches the
`<std::iter::Map<std::ops::Range<i32>,[closure@not-a-recursion-error.rs:5:30:
5:53]> as std::iter::IntoIterator>::Item = #_7t` resolution. Now
everybody else that attempts to look up the projection will just get
`#_7t` *without* any additional obligations. This obviously causes all
sorts of trouble (here a spurious `EvaluatedToAmbig` results in
specializations not being discarded
[here](https://github.com/rust-lang/rust/blob/9ca50bd4d50b55456e88a8c3ad8fcc9798f57522/src/librustc/traits/select.rs#L1705)).
The compiler works even with this projection cache gotcha because in most
cases during "one-pass evaluation". we tend to process obligations in LIFO
order - after an obligation is added to the cache, we process its nested
obligations before we do anything else (and if we have a cycle, we handle
it specifically) - which makes sure the inference variables are resolved
before they are used.
That "LIFO" order That was not done when projecting out of a closure, so
let's just fix that for the time being.
Fixes #38033.
|
|
|
|
Bump prerelease version
|
|
|
|
Backport #37691 to beta
|
|
This update of compiler-rt includes rust-lang/compiler-rt#26 which provides a
targeted fix to the powisf2 intrinsics to keep #37559 fixed but also address
the new issue of #37630. I've also [written up my thoughts][1] on why it appears
that this is the correct fix for now (hoepfully at least).
Closes #37630
[1]: https://github.com/rust-lang/compiler-rt/pull/26#issuecomment-259751998
|
|
Beta backport of #37775
|
|
If a rule is flagged with `default(true)` then the pseudo-rule `default:foo`
will include that. If a rule is also flagged with `.host(true)`, however, then
the rule shouldn't be included for targets that aren't in the host array. This
adds a filter to ensure we don't pull in host rules for targets by accident.
|
|
[beta] bootstrap: rust-docs is a default package
|
|
This will cause it to be built as part of `make dist`.
|
|
[beta] Update bootstrap cargo/compiler
|
|
|
|
|
|
Stabilize `..` in tuple (struct) patterns
I'd like to nominate `..` in tuple and tuple struct patterns for stabilization.
This feature is a relatively small extension to existing stable functionality and doesn't have known blockers.
The feature first appeared in Rust 1.10 6 months ago.
An example of use: https://github.com/rust-lang/rust/pull/36203
Closes https://github.com/rust-lang/rust/issues/33627
r? @nikomatsakis
|
|
fix silent overflows on `Step` impls
Part of https://github.com/rust-lang/rust/issues/36110
r? @eddyb
|
|
rustbuild: support MIPS host builds
There is a *little* code duplication, but primarily for sake of "match exhaustiveness". Let's blame Linux/MIPS for not exposing endianness explicitly in `uname -m` (that's user-space interface and as such is frozen).
Currently the build won't work as we have to wait for a new stage0 for the MIPS host compilers, but this paves the way to self-hosted Rust on MIPS. The cross-compiled MIPS binaries are confirmed to work on the Loongson 3A2000 (MIPS64r2-compatible) so we have plenty of confidence that they'll work on other MIPS platforms too, as Linux/MIPS user-space ABI is consistent across machines of the same bitness.
r? @alexcrichton
|
|
Remove mention of mipsel target_arch
This is the only remaining instance in rustc. All others were in the libc repo, removed with rust-lang/libc#445.
Actually there's more to clean in `libsyntax/abi.rs`, but let's save that for another commit...
|
|
Fix Arc::clone()'s MAX_REFCOUNT check (off-by-one)
Before, the strong count of an `Arc` could be set to
`MAX_REFCOUNT + 1`, because when this happened, `old_size` would
be exactly `MAX_REFCOUNT`. `Arc::clone()` would not abort.
This commit changes the check in `Arc::clone()` to also abort if
the old value is equal to `MAX_REFCOUNT`, because then the new
value will be equal to `MAX_REFCOUNT + 1`.
A test would require allocating memory for `isize::MAX` pointers.
This would probably crash any machine, so no test is submitted
with this commit.
|
|
There is a *little* code duplication, but primarily for sake of "match
exhaustiveness". Let's blame Linux/MIPS for not exposing endianness
explicitly in `uname -m` (that's user-space interface and as such is
frozen).
Currently the build won't work as we have to wait for a new stage0 for
the MIPS host compilers, but this paves the way to self-hosted Rust on
MIPS. The cross-compiled MIPS binaries are confirmed to work on the
Loongson 3A2000 (MIPS64r2-compatible) so we have plenty of confidence
that they'll work on other MIPS platforms too, as Linux/MIPS user-space
ABI is consistent across machines of the same bitness.
|
|
The `mipsel` `target_arch` was introduced with the initial MIPSel
support (rust-lang/rust@82ec1aef293ddc5c6373bd7f5ec323fafbdf7901),
but was subsequently removed with implementation of the Flexible Target
Specification (Rust RFC 0131,
rust-lang/rust@3a8f4ec32a80d372db2d02c76acba0276c4effd0).
This is the only remaining instance in rustc. All others are in the libc
repo, and are fixed in rust-lang/libc@b3676593f6930c32d947c59e210789bbfcb30960.
|
|
macros: improve shadowing checks
This PR improves macro-expanded shadowing checks to work with out-of-(pre)order expansion.
Out-of-order expansion became possible in #37084, so this technically a [breaking-change] for nightly.
The regression test from this PR is an example of code that would break.
r? @nrc
|
|
use arm abi blacklist for aarch64 fuchsia
r? @alexcrichton
|
|
Force static linking of LLVM
Run `llvm-config` with `--link-static` if available, to force static linking of LLVM.
This option was added in LLVM 3.8.
This is my first pull request, any feedback is welcome!
Fixes #36854
See also: #36996
|
|
|
|
The constant name `MAX_REFCOUNT` suggests that the value is a
_hard_ limit on the amount of references to an `Arc`. This is
a more soft limit however. This commit adds a comment to the
constant to annotate this.
See also: PR #37605
|
|
Add test for issue 18060.
Closes #18060
|
|
Run llvm-config with "--link-static" if available, to force static linking of LLVM.
This option was added in LLVM 3.8.
Fixes #36854
See also: #36996
|
|
|
|
[4/n] rustc: harden against InferOk having obligations in more cases.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37402) | [next](https://github.com/rust-lang/rust/pull/37408)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
This adds more asserts that `InferOk` results have no obligations, pending completion of #32730.
Each of these could accidentally drop obligations on the floor if they start getting produced by unification, and a future change does just that, in order to produce a "shallow success" (hopefully leading to ambiguities during trait selection), _without_ the possibility of an eventual success - mostly guarded by ICEs for now.
|
|
|
|
Add example using Self to reference
When I first came across `Self` I had a hard time finding references to it in the docs (and it's also been asked about on [StackOverflow](http://stackoverflow.com/questions/32304595/whats-the-difference-between-self-and-self).
I hope this example provides someone who comes across it for the first time a little more help. If there is a better way to show an example actually using `Self`, I'm happy to modify this. It was just the simplest place to start I could see.
|
|
Rollup of 24 pull requests
- Successful merges: #37255, #37317, #37408, #37410, #37422, #37427, #37470, #37501, #37537, #37556, #37557, #37564, #37565, #37566, #37569, #37574, #37577, #37579, #37583, #37585, #37586, #37587, #37589, #37596
- Failed merges: #37521, #37547
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add error when proc_macro_derive is used not on functions
Fixes #37590
|
