Rollup merge of #76498 - ehuss:update-cargo, r=ehuss
Update cargo
8 commits in 126907a7cfccbe93778530e6a6bbaa3adb6c515c..875e0123259b0b6299903fe4aea0a12ecde9324f
2020-08-31 20:42:11 +0000 to 2020-09-08 20:17:21 +0000
- Lowercase and remove periods in error messages for consistency (rust-lang/cargo#8655)
- Allow running build-man.sh from any directory (rust-lang/cargo#8682)
- docs: add details for cargo check pass where cargo build fail (rust-lang/cargo#8677)
- Fix nightly exported_priv_warning test. (rust-lang/cargo#8678)
- fix mdbook test with ```ignore/text/sh/console (rust-lang/cargo#8674)
- End CACHEDIR.TAG with newline (rust-lang/cargo#8672)
- Fixed the fossil repo initialization actually run commands (rust-lang/cargo#8671)
- Remove asciidoc attribute in cargo-metadata man page. (rust-lang/cargo#8670)
Rollup merge of #76402 - elichai:patch-2, r=wesleywiser
Update linker-plugin-lto.md to contain up to rust 1.46
Hi,
this is the same as https://github.com/rust-lang/rust/pull/72290, if anyone has suggestions on how to automate this please say :)
otherwise, you can check the versions I've added via:
Rollup merge of #76401 - JulianKnodt:i68366, r=lcnr
Add help note to unconstrained const parameter
Resolves #68366, since it is currently intended behaviour.
If demonstrating `T -> U` is injective, there should be an additional word that it is not **yet** supported.
Rollup merge of #76389 - MaulingMonkey:pr-natvis-hashmap-vsc, r=petrochenkov
Fix HashMap visualizers in Visual Studio (Code)
CDB (as used in unit tests) doesn't care that we're using static_cast between unrelated types (`u8*` to `tuple<$T1, $T2>*`).
Visual Studio & Visual Studio Code care. These should've been reinterpret_cast or C casts.
Credit to @petrochenkov per https://github.com/rust-lang/rust/issues/76352 for helping catch this.
### Testing
```cmd
x.py test --stage 1 src/tools/tidy
x.py test --stage 1 --build x86_64-pc-windows-msvc src\test\debuginfo
```
Rollup merge of #76355 - calebcartwright:reduce-rustfmt-visibility, r=nikomatsakis
remove public visibility previously needed for rustfmt
`submod_path_from_attr` in rustc_expand::module was previously public because it was also consumed by rustfmt. However, we've done a bit of refactoring in rustfmt and no longer need to use this function.
This changes the visibility to the parent mod as was originally going to be done before the rustfmt dependency was realized (https://github.com/rust-lang/rust/commit/c189565edc5c9fc516170885b3a3061b936205fb#diff-cd1b379893bae95f7991d5a3f3c6d337R201)
Auto merge of #76332 - Mark-Simulacrum:bootstrap-llvm, r=pietroalbini
Add rust-dev component to support rustc development
This is preparatory work for permitting rustc developers to use CI-built LLVM rather than building it locally. Unlike distro-built LLVM, CI built LLVM is essentially guaranteed to behave perfectly for local development -- it is fully up to date, and carries all necessary patches.
This is a separate PR from #76349 because it needs to land before that one, since we want a master build with the full CI LLVM to be available for easier testing.
Auto merge of #76423 - Mark-Simulacrum:stable-bootstrap, r=jyn514
Make bootstrap build on beta
This is generally a good idea, and will help with being able to build bootstrap
without Python over time as it means we can "just" build with cargo +beta build
rather than needing the user to set environment variables. This is a minor step,
but a necessary one on that road.
Auto merge of #75585 - RalfJung:demotion, r=oli-obk
Do not promote &mut of a non-ZST ever
Since ~pre-1.0~ 1.36, we have accepted code like this:
```rust
static mut TEST: &'static mut [i32] = {
let x = &mut [1,2,3];
x
};
```
I tracked it back to https://github.com/rust-lang/rust/pull/21744, but unfortunately could not find any discussion or RFC that would explain why we thought this was a good idea. And it's not, it breaks all sorts of things -- see https://github.com/rust-lang/rust/issues/75556.
To fix https://github.com/rust-lang/rust/issues/75556, we have to stop promoting non-ZST mutable references no matter the context, which is what this PR does. It's a breaking change.
Notice that this still works, since it does not rely on promotion:
```rust
static mut TEST: &'static mut [i32] = &mut [0,1,2];
```
Auto merge of #76210 - Mark-Simulacrum:tracing-update, r=oli-obk
Tracing update
This does not bring the more significant changes that are coming down the pipeline, but since I've already prepared the PR leaving it up :)
See https://github.com/rust-lang/rust/pull/76210#issuecomment-685065938:
> Unfortunately, tracing 0.1.20 — which contained the change to reduce the amount of code generated by the tracing macros — had to be yanked, as it broke previously-compiling code for some downstream crates. I've not yet had the chance to fix this and release a new patch. So, in order to benefit from the changes to reduce generated code, you'll need to wait until there's a new version of tracing as well as tracing-attributes and tracing-core.
Auto merge of #75138 - jumbatm:session-diagnostic-derive, r=oli-obk
Add derive macro for specifying diagnostics using attributes.
Introduces `#[derive(SessionDiagnostic)]`, a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently, the following attributes have been implemented:
- `#[code = "..."]` -- this sets the Diagnostic's error code, and must be provided on the struct iself (ie, not on a field). Equivalent to calling `code`.
- `#[message = "..."]` -- this sets the Diagnostic's primary error message.
- `#[label = "..."]` -- this must be applied to fields of type `Span`, and is equivalent to `span_label`
- `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span, Applicability)`, and is equivalent to calling `span_suggestion`. Valid arguments are:
- `message = "..."` -- this sets the suggestion message.
- (Optional) `code = "..."` -- this suggests code for the suggestion. Defaults to empty.
`suggestion`also comes with other variants: `#[suggestion_short(..)]`, `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys.
Within the strings passed to each attribute, fields can be referenced without needing to be passed explicitly into the format string -- eg, `#[error = "{ident} already declared"] ` will set the error message to `format!("{} already declared", &self.ident)`. Any fields on the struct can be referenced in this way.
Additionally, for any of these attributes, Option fields can be used to only optionally apply the decoration -- for example:
```rust
#[derive(SessionDiagnostic)]
#[code = "E0123"]
struct SomeKindOfError {
...
#[suggestion(message = "informative error message")]
opt_sugg: Option<(Span, Applicability)>
...
}
```
will not emit a suggestion if `opt_sugg` is `None`.
We plan on iterating on this macro further; this PR is a start.
Auto merge of #76044 - ecstatic-morse:dataflow-lattice, r=oli-obk
Support dataflow problems on arbitrary lattices
This PR implements last of the proposed extensions I mentioned in the design meeting for the original dataflow refactor. It extends the current dataflow framework to work with arbitrary lattices, not just `BitSet`s. This is a prerequisite for dataflow-enabled MIR const-propagation. Personally, I am skeptical of the usefulness of doing const-propagation pre-monomorphization, since many useful constants only become known after monomorphization (e.g. `size_of::<T>()`) and users have a natural tendency to hand-optimize the rest. It's probably worth exprimenting with, however, and others have shown interest cc `@rust-lang/wg-mir-opt.`
The `Idx` associated type is moved from `AnalysisDomain` to `GenKillAnalysis` and replaced with an associated `Domain` type that must implement `JoinSemiLattice`. Like before, each `Analysis` defines the "bottom value" for its domain, but can no longer override the dataflow join operator. Analyses that want to use set intersection must now use the `lattice::Dual` newtype. `GenKillAnalysis` impls have an additional requirement that `Self::Domain: BorrowMut<BitSet<Self::Idx>>`, which effectively means that they must use `BitSet<Self::Idx>` or `lattice::Dual<BitSet<Self::Idx>>` as their domain.
Most of these changes were mechanical. However, because a `Domain` is no longer always a powerset of some index type, we can no longer use an `IndexVec<BasicBlock, GenKillSet<A::Idx>>>` to store cached block transfer functions. Instead, we use a boxed `dyn Fn` trait object. I discuss a few alternatives to the current approach in a commit message.
The majority of new lines of code are to preserve existing Graphviz diagrams for those unlucky enough to have to debug dataflow analyses. I find these diagrams incredibly useful when things are going wrong and considered regressing them unacceptable, especially the pretty-printing of `MovePathIndex`s, which are used in many dataflow analyses. This required a parallel `fmt` trait used only for printing dataflow domains, as well as a refactoring of the `graphviz` module now that we cannot expect the domain to be a `BitSet`. Some features did have to be removed, such as the gen/kill display mode (which I didn't use but existed to mirror the output of the old dataflow framework) and line wrapping. Since I had to rewrite much of it anyway, I took the opportunity to switch to a `Visitor` for printing dataflow state diffs instead of using cursors, which are error prone for code that must be generic over both forward and backward analyses. As a side-effect of this change, we no longer have quadratic behavior when writing graphviz diagrams for backward dataflow analyses.
Mark Rousskov [Fri, 4 Sep 2020 17:59:14 +0000 (13:59 -0400)]
Dedicated rust development tarball
This currently includes libLLVM, llvm-config, and FileCheck, but will perhaps
expand to more tooling overtime. It should be considered entirely unstable and
may change at any time.
Mark Rousskov [Sun, 6 Sep 2020 23:38:26 +0000 (19:38 -0400)]
Make bootstrap build on stable
This is generally a good idea, and will help with being able to build bootstrap
without Python over time as it means we can "just" build with cargo +beta build
rather than needing the user to set environment variables. This is a minor step,
but a necessary one on that road.
Auto merge of #76422 - Dylan-DPC:rollup-0579ucb, r=Dylan-DPC
Rollup of 18 pull requests
Successful merges:
- #76273 (Move some Vec UI tests into alloc unit tests)
- #76274 (Allow try blocks as the argument to return expressions)
- #76287 (Remove an unnecessary allowed lint)
- #76293 (Implementation of incompatible features error)
- #76299 (Make `Ipv4Addr` and `Ipv6Addr` const tests unit tests under `library`)
- #76302 (Address review comments on `Peekable::next_if`)
- #76303 (Link to `#capacity-and-reallocation` when using with_capacity)
- #76305 (Move various ui const tests to `library`)
- #76309 (Indent a note to make folding work nicer)
- #76312 (time.rs: Make spelling of "Darwin" consistent)
- #76318 (Use ops::ControlFlow in rustc_data_structures::graph::iterate)
- #76324 (Move Vec slice UI tests in library)
- #76338 (add some intra-doc links to `Iterator`)
- #76340 (Remove unused duplicated `trivial_dropck_outlives`)
- #76344 (Improve docs for `std::env::args()`)
- #76346 (Docs: nlink example typo)
- #76358 (Minor grammar fix in doc comment for soft-deprecated methods)
- #76364 (Disable atomics on avr target.)
Failed merges:
- #76304 (Make delegation methods of `std::net::IpAddr` unstably const)
Rollup merge of #76318 - scottmcm:one-control-flow, r=ecstatic-morse
Use ops::ControlFlow in rustc_data_structures::graph::iterate
Since I only know about this because you mentioned it,
r? @ecstatic-morse
If we're not supposed to use new `core` things in compiler for a while then feel free to close, but it felt reasonable to merge the two types since they're the same, and it might be convenient for people to use `?` in their traversal code.
(This doesn't do the type parameter swap; NoraCodes has signed up to do that one.)
Rollup merge of #76312 - numbermaniac:patch-1, r=shepmaster
time.rs: Make spelling of "Darwin" consistent
On line 89 of this file, the OS name is written as "Darwin", but on line 162 it is written in all-caps. Darwin is usually spelt as a standard proper noun, i.e. "Darwin", rather than in all-caps.
This change makes that form consistent in both places.
Rollup merge of #76305 - CDirkx:const-tests, r=matklad
Move various ui const tests to `library`
Move:
- `src\test\ui\consts\const-nonzero.rs` to `library\core`
- `src\test\ui\consts\ascii.rs` to `library\core`
- `src\test\ui\consts\cow-is-borrowed` to `library\alloc`
Rollup merge of #76274 - scottmcm:fix-76271, r=petrochenkov
Allow try blocks as the argument to return expressions
Fixes #76271
I don't think this needs to be edition-aware (phew) since `return try` in 2015 is also the start of an expression, just with a struct literal instead of a block (`return try { x: 4, y: 5 }`).
Rollup merge of #76273 - CraftSpider:master, r=matklad
Move some Vec UI tests into alloc unit tests
A bit of work towards #76268, makes a number of the Vec UI tests that are simply running code into unit tests. Ensured that they are being run when testing liballoc locally.
Auto merge of #75949 - vext01:filter-docs, r=jyn514
Try to improve the documentation of `filter()` and `filter_map()`.
I believe the documentation is currently a little misleading.
For example, in the docs for `filter()`:
> If the closure returns `false`, it will try again, and call the closure on
> the next element, seeing if it passes the test.
This kind of implies that if the closure returns true then we *don't* "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.
This change tries to clarify that by removing the uses of "try again"
altogether.
Auto merge of #76390 - MaulingMonkey:pr-min-cdb-version, r=petrochenkov
debuginfo: Ignore HashMap .natvis tests before cdb 10.0.18362.1
CDB <10.0.18362.1 chokes on casts within HashMap's natvis visualizers. This PR adds support for "min-cdb-version" (per existing "min-gdb-version" and "min-lldb-version" filters) and uses it. CI uses a more recent version of CDB for testing and thus should still run the tests.
Credit to @petrochenkov per https://github.com/rust-lang/rust/issues/76352 for helping catch this.
### SDK Testing
| Win 10 SDK | x64 CDB | rustc 1.47.0-nightly (bf4342114 2020-08-25) built-in .natvis | Note |
| --------------------------------------------------------------------- | ----------------- | ------------------------------------------------------------- | ---- |
| [10.0.19041.0](https://go.microsoft.com/fwlink/p/?linkid=2120843) | 10.0.19041.1 | ✔️ | CI
| [10.0.18362.1](https://go.microsoft.com/fwlink/?linkid=2083338) | 10.0.18362.1 | ✔️ | MaulingMonkey
| [10.0.17763.0](https://go.microsoft.com/fwlink/p/?LinkID=2033908) | 10.0.17763.132 | ❌ `Unable to find type 'tuple<u64,u64> *' for cast.`
| [10.0.17134.12](https://go.microsoft.com/fwlink/p/?linkid=870807) | 10.0.17134.12 | ❌ `Unable to find type 'tuple<u64,u64> *' for cast.`
| [10.0.16299.91](https://go.microsoft.com/fwlink/p/?linkid=864422) | 10.0.16299.91 | ❌ `Unable to find type 'tuple<u64,u64> *' for cast.`
| [10.0.15063.468](https://go.microsoft.com/fwlink/p/?LinkId=845298) | 10.0.15063.468 | ❌ `Unable to find type 'tuple<u64,u64> *' for cast.`
| [10.0.14393.795](https://go.microsoft.com/fwlink/p/?LinkId=838916) | 10.0.14321.1024 | ❌ `Unable to find type 'tuple<u64,u64> *' for cast.` | petrochenkov
| [10.0.10586.212](https://go.microsoft.com/fwlink/p/?LinkID=698771) | 10.0.10586.567 | ❌ `Expected ')' at '+ 1)].__1'`
| [10.0.10240](https://go.microsoft.com/fwlink/p/?LinkId=619296) | 10.0.10240? | ❔ Untested
### Rust Testing
```cmd
x.py test --stage 1 src/tools/tidy
x.py test --stage 1 --build x86_64-pc-windows-msvc src\test\debuginfo
```
Also verified test still fails when intentionally broken w/ CDB version >= min-cdb-version.
Auto merge of #76331 - Aaron1011:fix/group-compat-hack-test, r=petrochenkov
Account for version number in NtIdent hack
Issue #74616 tracks a backwards-compatibility hack for certain macros.
This has is implemented by hard-coding the filenames and macro names of
certain code that we want to continue to compile.
However, the initial implementation of the hack was based on the
directory structure when building the crate from its repository (e.g.
`js-sys/src/lib.rs`). When the crate is build as a dependency, it will
include a version number from the clone from the cargo registry (e.g.
`js-sys-0.3.17/src/lib.rs`), which would fail the check.
This commit modifies the backwards-compatibility hack to check that
desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the
proper part of the path.
See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646
for more details.
CDB doesn't care that you're using static_cast between unrelated types.
VS(C) does. These should've been reinterpret_cast or C casts.
Cast is from e.g. `u8*` to `tuple<$T1, $T2>*`
Auto merge of #76217 - RalfJung:maybe-uninit-slice, r=KodrAus
rename MaybeUninit slice methods
The `first` methods conceptually point to the whole slice, not just its first element, so rename them to be consistent with the raw ptr methods on ref-slices.
Also, do the equivalent of https://github.com/rust-lang/rust/pull/76047 for the slice reference getters, and make them part of https://github.com/rust-lang/rust/issues/63569 (so far they somehow had no tracking issue).
Edd Barrett [Wed, 26 Aug 2020 16:39:43 +0000 (17:39 +0100)]
Improve the documentation of `filter()` and `filter_map()`.
I believe the documentation is currently a little misleading.
For example, in the docs for `filter()`:
> If the closure returns `false`, it will try again, and call the closure on
> the next element, seeing if it passes the test.
This kind of implies that if the closure returns true then we *don't* "try
again" and no further elements are considered. In actuality that's not the
case, every element is tried regardless of what happened with the previous
element.
This change tries to clarify that by removing the uses of "try again"
altogether.
Auto merge of #75872 - mati865:pgo-tests, r=petrochenkov
Enable some of profiler tests on Windows-gnu
CC https://github.com/rust-lang/rust/issues/61266
Because of force-push GitHub didn't let me reopen https://github.com/rust-lang/rust/pull/75184
Because of the GCC miscompilation, generated binaries either segfault or `.profraw` is malformed. Clang works fine but we can't use it on the CI.
However we can still test the IR for the proper instrumentation so let's do it.
projects / rust.git / log