The thrilling conclusion of the cross-crate macro saga in rustdoc! After https://github.com/rust-lang/rust/pull/51425 made sure we saw all the namespaces of an import (and prevented us from losing the `vec!` macro in std's documentation), here is the PR to handle cross-crate macro re-exports at the same time as everything else. This way, attributes like `#[doc(hidden)]` and `#[doc(no_inline)]` can be used to control how the documentation for these macros is seen, rather than rustdoc inlining every macro every time.
Auto merge of #51935 - cramertj:unpin-references, r=withoutboats
Unpin references
I also considered adding an impl for raw pointers as well, but that makes it easy to accidentally have unsound owning-collections that might otherwise be able to project pinned-ness (e.g. `Box`).
Now we have removed the `Self: Foo` from the trait. However, we still
add it to the trait ITEM. This is because when people do things like
`<T as Foo>::bar()`, they still need to prove that `T: Foo`, and
having it in the `predicates_of` seems to be the cleanest way to
ensure that happens right now (otherwise, we'd need special case code
in various places):
However, we sometimes want to get the list of *just* the predicates
truly defined on a trait item (e.g., for chalk, but also for a few
other bits of code). For that, we define `predicates_defined_on`,
which does not contain the `Self: Foo` predicate yet, and we plumb
that through metadata and so forth.
---
I'm assigning @eddyb as the main reviewer, but I thought I might delegate to scalexm for this one in any case. I also want to post an alternative that I'll leave in the comments; it occurred to me as I was writing. =)
Auto merge of #51900 - PramodBisht:51813_b, r=nikomatsakis
introduce dirty list to dataflow
@nikomatsakis my naive implementation never worked, So, I decided to implement using `work_queue` data structure. This PR also includes your commits from `nll-liveness-dirty-list` branch. Those commits should not visible once your branch is merged.
Auto merge of #52014 - pietroalbini:rollup, r=pietroalbini
Rollup of 13 pull requests
Successful merges:
- #51548 (Initialize LLVM's AMDGPU target machine, if available.)
- #51809 (Add read_exact_at and write_all_at methods to FileExt on unix)
- #51914 (add outlives annotations to `BTreeMap`)
- #51958 (Show known meta items in unknown meta items error)
- #51973 (Make Stdio handle UnwindSafe)
- #51977 (bootstrap: tests should use rustc from config.toml)
- #51978 (Do not suggest changes to str literal if it isn't one)
- #51979 (Get rid of `TyImplTraitExistential`)
- #51980 (Emit column info in debuginfo for non msvc like targets)
- #51982 (incr.comp.: Take names of children into account when computing the ICH of a module's HIR.)
- #51997 (add entry for cargo-metadata feature to RELEASES)
- #52004 (toolstate: Fixed detection of changed submodule, and other fixes.)
- #52006 ( Change --keep-stage to apply more often)
Pietro Albini [Tue, 3 Jul 2018 09:31:13 +0000 (11:31 +0200)]
Rollup merge of #52006 - Mark-Simulacrum:keep-stage-fix, r=alexcrichton
Change --keep-stage to apply more often
Previously, the --keep-stage argument would only function for compilers
that were depended on by future stages. For example, if trying to build
a stage 1 compiler you could --keep-stage 0 to avoid re-building the
stage 0 compiler. However, this is often not what users want in
practice.
The new implementation essentially skips builds all higher stages of the
compiler, so an argument of 1 to keep-stage will skip rebuilds of the
libraries, just linking them into the sysroot. This is unlikely to work
well in cases where metadata or similar changes have been made, but is
likely fine otherwise.
This change is somewhat untested, but since it shouldn't have any effect
except with --keep-stage, I don't see that as a large problem.
r? @alexcrichton
cc @nikomatsakis - I believe you wanted this functionality
Pietro Albini [Tue, 3 Jul 2018 09:31:12 +0000 (11:31 +0200)]
Rollup merge of #52004 - kennytm:toolstate-fixes, r=Mark-Simulacrum
toolstate: Fixed detection of changed submodule, and other fixes.
1. Make sure that if a submodule is updated but failed to test-pass, we'll block the merge.
2. Make sure failure on external docs (nomicon/RBE/etc) are properly checked.
3. If the commit message starts with "Update RLS" (or clippy etc), automatically run the "tools" job on the PR, so that we could know if the update failed before merging.
Pietro Albini [Tue, 3 Jul 2018 09:31:04 +0000 (11:31 +0200)]
Rollup merge of #51977 - mnd:fix-bootstrap-test-with-local-stage0, r=simulacrum
bootstrap: tests should use rustc from config.toml
Tests should always use "rustc" and "cargo" from config.toml instead of assuming that stage0 binaries was downloaded to build directory.
Without this change `./x.py test src/bootstrap` will always try to use `build/ARCH/stage0/bin/rustc` file as compiler, but when we use local compiler to bootstrap this file does not exist.
Pietro Albini [Tue, 3 Jul 2018 09:30:59 +0000 (11:30 +0200)]
Rollup merge of #51809 - drrlvn:rw_exact_all_at, r=alexcrichton
Add read_exact_at and write_all_at methods to FileExt on unix
This PR adds `FileExt::read_exact_at()` and `FileExt::write_all_at()`, which are to `read_at()` and `write_at()` as `read_exact()` and `write_all()` are to `read()` and `write()`. This allows the user to not have to deal with `ErrorKind::Interrupted` and calling the functions in a loop.
I was unsure as to how to mark these new methods so I marked them `unstable`, please let me know if I should have done it differently.
I asked in Discord and was told that as this change is small it does not require an RFC.
This fixes #49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`).
They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](https://github.com/rust-lang/rfcs/pull/1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms.
This PR gives up on this possiblity for two reasons:
* Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later.
* For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
Mark Rousskov [Mon, 2 Jul 2018 22:04:58 +0000 (16:04 -0600)]
Change --keep-stage to apply more
Previously, the --keep-stage argument would only function for compilers
that were depended on by future stages. For example, if trying to build
a stage 1 compiler you could --keep-stage 0 to avoid re-building the
stage 0 compiler. However, this is often not what users want in
practice.
The new implementation essentially skips builds all higher stages of the
compiler, so an argument of 1 to keep-stage will skip rebuilds of the
libraries, just linking them into the sysroot. This is unlikely to work
well in cases where metadata or similar changes have been made, but is
likely fine otherwise.
This change is somewhat untested, but since it shouldn't have any effect
except with --keep-stage, I don't see that as a large problem.
Auto merge of #51944 - MajorBreakfast:generic-future-obj, r=cramertj
Make custom trait object for `Future` generic
- `TaskObj` -> `FutureObj<'static, ()>`
- The `impl From<...> for FutureObj<'a, T>` impls are impossible because of the type parameter `T`. The impl has to live in libstd, but `FutureObj<'a, T>` is from libcore. Therefore `Into<FutureObj<'a, T>>` was implemented instead. Edit: This didn‘t compile without warnings. I am now using non-generic Form impls.
See https://github.com/rust-lang-nursery/futures-rs/issues/1058
Niko Matsakis [Mon, 2 Jul 2018 14:35:30 +0000 (10:35 -0400)]
introduce `predicates_defined_on` for traits
This new query returns only the predicates *directly defined* on an
item (in contrast to the more common `predicates_of`, which returns
the predicates that must be proven to reference an item). These two
sets are almost always identical except for traits, where
`predicates_of` includes an artificial `Self: Trait<...>` predicate
(basically saying that you cannot use a trait item without proving
that the trait is implemented for the type parameters).
This new query is only used in chalk lowering, where this artificial
`Self: Trait` predicate is problematic. We encode it in metadata but
only where needed since it is kind of repetitive with existing
information.
Niko Matsakis [Fri, 29 Jun 2018 09:31:59 +0000 (05:31 -0400)]
prove defaults meet WF requirements, not that they are WF
If we have
```rust
struct Foo<T: Copy = String> { .. }
```
the old code would have proven that `String: Copy` was WF -- this,
incidentally, also proved that `String: Copy`. The new code just
proves `String: Copy` directly.
Zack M. Davis [Sat, 2 Jun 2018 23:49:34 +0000 (16:49 -0700)]
add FIXMEs pleading for post-@ edit of commentary on mem_categorization
(The present author fears not being knowledgeable enough to rewrite the
comments unilaterally; merely calling it out is a lazy half-measure, but
at least doesn't actively make things worse the way an ill-informed
rewrite would.)
#50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix.
Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private).
Preventing `const fn` from allowing to work around the ban on reading from statics would cripple `const fn` almost into uselessness.
Additionally, the limitation for reading from statics comes from the old const evaluator(s) and is not shared by `miri`.
This PR loosens the rules around use of statics to allow statics to evaluate other statics by value, allowing all of the above examples to compile and run successfully.
Reads from extern (foreign) statics are however still disallowed by miri, because there is no compile-time value to be read.
```rust
extern static A: u32;
static B: u32 = A; // error
```
This opens up a new avenue of potential issues, as a static can now not just refer to other statics or read from other statics, but even contain references that point into itself.
While it might seem like this could cause subtle bugs like allowing a static to be initialized by its own value, this is inherently impossible in miri.
Reading from a static causes the `const_eval` query for that static to be invoked. Calling the `const_eval` query for a static while already inside the `const_eval` query of said static will cause cycle errors.
It is not possible to accidentally create a bug in miri that would enable initializing a static with itself, because the memory of the static *does not exist* while being initialized.
The memory is not uninitialized, it is not there. Thus any change that would accidentally allow reading from a not yet initialized static would cause ICEs.
Tests have been modified according to the new rules, and new tests have been added for writing to `static mut`s within definitions of statics (which needs to fail), and incremental compilation with complex/interlinking static definitions.
Note that incremental compilation did not need to be adjusted, because all of this was already possible before with workarounds (like intermediate `const fn`s) and the encoding/decoding already supports all the possible cases.
Auto merge of #51969 - pietroalbini:rollup, r=pietroalbini
Rollup of 7 pull requests
Successful merges:
- #51511 (Stabilize Iterator::flatten in 1.29, fixes #48213.)
- #51853 (Fix some doc links)
- #51890 (Fix inconsequential typo in GlobalAlloc doc example)
- #51920 (use literal span for concrete type suggestion)
- #51921 (improve the error message when `#[panic_implementation]` is missing)
- #51922 (rename the llvm-tools component to llvm-tools-preview and tweak its image)
- #51961 (Fix typo in /src/librustc_resolve/lib.rs)
Pietro Albini [Sun, 1 Jul 2018 19:18:43 +0000 (21:18 +0200)]
Rollup merge of #51511 - Centril:feature/stabilize_iterator_flatten, r=SimonSapin
Stabilize Iterator::flatten in 1.29, fixes #48213.
This PR stabilizes [`Iterator::flatten`](https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.flatten) in *version 1.29* (1.28 goes to beta in 10 days, I don't think there's enough time to land it in that time, but let's see...).
Tracking issue is: #48213.
cc @bluss re. itertools.
r? @SimonSapin
ping @pietroalbini -- let's do a crater run when this passes CI :)
Auto merge of #51833 - wesleywiser:faster_large_constant_arrays, r=oli-obk
Speed up compilation of large constant arrays
This is a different approach to #51672 as suggested by @oli-obk. Rather
than write each repeated value one-by-one, we write the first one and
then copy its value directly into the remaining memory.
With this change, the [toy program](https://github.com/rust-lang/rust/blob/c2f4744d2db4e162df824d0bd0b093ba4b351545/src/test/run-pass/mir_heavy_promoted.rs) goes from 63 seconds to 19 seconds on my machine.
Edit: Inlining `Size::bytes()` saves an additional 6 seconds dropping the total time to 13 seconds on my machine.
Zack M. Davis [Sun, 1 Jul 2018 18:05:10 +0000 (11:05 -0700)]
call it `hir::VisibilityKind` instead of `hir::Visibility_:*`
It was pointed out in review that the glob-exported
underscore-suffixed convention for `Spanned` HIR nodes is no longer
preferred: see February 2016's #31487 for AST's migration away from
this style towards properly namespaced NodeKind enums.
Auto merge of #51536 - davidtwco:nll-dyn-trait-underscore-error-improvements, r=nikomatsakis
NLL: bad error message when converting anonymous lifetime to `'static`
Contributes to #46983. This PR doesn't introduce fantastic errors, but it should hopefully lay some groundwork for diagnostic improvements.
r? @nikomatsakis
projects / rust.git / log