Dylan DPC [Fri, 29 May 2020 18:21:22 +0000 (20:21 +0200)]
Rollup merge of #72591 - sexxi-goose:rename_upvar_list-to-closure_captures, r=matthewjasper
librustc_middle: Rename upvar_list to closure_captures
As part of supporting RFC 2229, we will be capturing all the places that
are mentioned in a closure. Currently the `upvar_list` field gives access to a `FxIndexMap<HirId, Upvar>` map. Eventually this will change, with the `upvar_list` having a more general structure that expresses captured paths, not just the mentioned `upvars`. We will make those changes in subsequent PRs.
This commit modifies the name of the `upvar_list` map to `closure_captures` in `TypeckTables`.
Dylan DPC [Fri, 29 May 2020 18:21:18 +0000 (20:21 +0200)]
Rollup merge of #72568 - golddranks:add_total_cmp_to_floats, r=sfackler
Implement total_cmp for f32, f64
# Overview
* Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that, unlike the standard `partial_cmp`, is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate.
* The method has an API similar to `cmp`: `pub fn total_cmp(&self, other: &Self) -> crate::cmp::Ordering { ... }`.
* Implements tests.
* Has documentation.
# Justification for the API
* Total ordering for `f32` and `f64` has been discussed many time before:
* https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701
* https://github.com/rust-lang/rfcs/issues/1249
* https://github.com/rust-lang/rust/pull/53938
* https://github.com/rust-lang/rust/issues/5585
* The lack of total ordering leads to frequent complaints, especially from people new to Rust.
* This is an ergonomics issue that needs to be addressed.
* However, the default behaviour of implementing only `PartialOrd` is intentional, as relaxing it might lead to correctness issues.
* Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is, however not easy to add because of the large API surface added.
* As a minimal step that hopefully proves uncontroversial, we can implement a stand-alone method `total_cmp` on floating point types.
* I expect adding such methods should be uncontroversial because...
* Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day.
* It implements functionality that is standardised. (IEEE 754, 2008 rev. §5.10 Note, that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.)
* With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion, providing additional helper methods is a minimal way of adding ordering functionality.
* Not also does it allow easily using aforementioned APIs, it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper, if needed.
Dylan DPC [Fri, 29 May 2020 18:21:17 +0000 (20:21 +0200)]
Rollup merge of #72465 - tmiasko:liveness-upvars, r=nikomatsakis
Warn about unused captured variables
Include captured variables in liveness analysis. Warn when captured variables
are unused (but possibly read or written to). Warn about dead assignments to
captured variables.
Dylan DPC [Fri, 29 May 2020 18:21:15 +0000 (20:21 +0200)]
Rollup merge of #72398 - Lucretiel:ip-socket-display, r=Mark-Simulacrum
SocketAddr and friends now correctly pad its content
Currently, `IpAddr` and friends correctly respect formatting parameters when printing via `Display`. This PR makes SocketAddr and friends do the same thing.
Dylan DPC [Fri, 29 May 2020 18:21:11 +0000 (20:21 +0200)]
Rollup merge of #72310 - jyn514:peekable-next-if, r=dtolnay
Add Peekable::next_if
Prior art:
`rust_analyzer` uses [`Parser::eat`](https://github.com/rust-analyzer/rust-analyzer/blob/50f4ae798b7c54d417ee88455b87fd0477473150/crates/ra_parser/src/parser.rs#L94), which is `next_if` specialized to `|y| self.next_if(|x| x == y)`.
Basically every other parser I've run into in Rust has an equivalent of `Parser::eat`; see for example
Possible extensions: A specialization of `next_if` to using `Eq::eq`. The only difficulty here is the naming - maybe `next_if_eq`?
Alternatives:
- Instead of `func: impl FnOnce(&I::Item) -> bool`, use `func: impl FnOnce(I::Item) -> Option<I::Item>`. This has the advantage that `func` can move the value if necessary, but means that there is no guarantee `func` will return the same value it was given.
- Instead of `fn next_if(...) -> Option<I::Item>`, use `fn next_if(...) -> bool`. This makes the common case of `iter.next_if(f).is_some()` easier, but makes the unusual case impossible.
Bikeshedding on naming:
- `next_if` could be renamed to `consume_if` (to match `eat`, but a little more formally)
- `next_if_eq` could be renamed to `consume`. This is more concise but less self-explanatory if you haven't written a lot of parsers.
- Both of the above, but with `consume` replaced by `eat`.
bors [Fri, 29 May 2020 07:52:06 +0000 (07:52 +0000)]
Auto merge of #72727 - JohnTitor:rollup-nni16m2, r=JohnTitor
Rollup of 11 pull requests
Successful merges:
- #71633 (Impl Error for Infallible)
- #71843 (Tweak and stabilize AtomicN::fetch_update)
- #72288 (Stabilization of weak-into-raw)
- #72324 (Stabilize AtomicN::fetch_min and AtomicN::fetch_max)
- #72452 (Clarified the documentation for Formatter::precision)
- #72495 (Improve E0601 explanation)
- #72534 (Improve missing `@` in slice binding pattern diagnostics)
- #72547 (Added a codegen test for a recent optimization for overflow-checks=on)
- #72711 (remove redundant `mk_const`)
- #72713 (Whitelist #[allow_internal_unstable])
- #72720 (Clarify the documentation of `take`)
```
error: expected one of `,`, `@`, `]`, or `|`, found `..`
--> src/main.rs:5:20
|
5 | [h, ref ts..] => foo(c, n - h) + foo(ts, n),
| ^^ expected one of `,`, `@`, `]`, or `|`
|
help: if you meant to bind the contents of the rest of the array pattern into `ts`, use `@`
|
5 | [h, ref ts @ ..] => foo(c, n - h) + foo(ts, n),
| ^
Yuki Okushi [Fri, 29 May 2020 06:06:57 +0000 (15:06 +0900)]
Rollup merge of #72324 - Amanieu:atomic_minmax, r=dtolnay
Stabilize AtomicN::fetch_min and AtomicN::fetch_max
Some architectures (ARMv8.1 LSE and RISC-V) have specific instructions for atomic min/max which the compiler can only generate through explicit instrinsics.
Yuki Okushi [Fri, 29 May 2020 06:06:55 +0000 (15:06 +0900)]
Rollup merge of #72288 - vorner:stabilize-weak-into-raw, r=dtolnay
Stabilization of weak-into-raw
Closes #60728.
There are also two removals of `#![feature(weak_into_raw)]` in the `src/tools/miri` submodule. How should I synchronize the changes with there?
* I can ignore it for now and once this gets merged, update the tool, send a pull request to that one and then reference the changes to rustc.
* I could try submitting the changes to miri first, but then the build would fail there, because the attribute would still be needed.
I think the first one is the correct one, extrapolating from the contributing guidelines (even though they speak about breaking the tools and this should not break it, as extra feature should not hurt).
Yuki Okushi [Fri, 29 May 2020 06:06:53 +0000 (15:06 +0900)]
Rollup merge of #71843 - sfackler:cas-loop-cleanup, r=dtolnay
Tweak and stabilize AtomicN::fetch_update
The fetch_update method implements a compare-and-swap loop to update the value in an atomic to an arbitrary value computed by a closure.
I've applied a few tweaks suggested by @mystor in this comment on the tracking issue: https://github.com/rust-lang/rust/issues/48655#issuecomment-496036553. Specifically, the load and store ordering arguments have been swapped to match with the orderings of `compare_exchange`, and the closure has been moved from the first to last argument.
Moving the closure to the last argument is a change away from other methods on the atomic types which place the ordering(s) last, but matches with the broad convention that closure arguments come last in functions. In particular, rustfmt style lays calls with multi-line closures out more cleanly when the closure comes last.
Yuki Okushi [Fri, 29 May 2020 06:06:48 +0000 (15:06 +0900)]
Rollup merge of #71633 - a1phyr:infallible_error, r=dtolnay
Impl Error for Infallible
This PR only changes the place where `impl Error for Infallible` is documented, as one could think that it is not the case when reading https://doc.rust-lang.org/nightly/std/convert/enum.Infallible.html.
bors [Fri, 29 May 2020 04:05:03 +0000 (04:05 +0000)]
Auto merge of #72506 - Nadrieril:fix-72476, r=matthewjasper
Exhaustiveness checking: work around type normalization issues
This should resolve https://github.com/rust-lang/rust/issues/72476 and probably https://github.com/rust-lang/rust/issues/72467.
This is a bit hacky but that's actually what the code was doing before https://github.com/rust-lang/rust/pull/71930. I'm essentially reverting https://github.com/rust-lang/rust/commit/e5a2cd526a6ad92b90dda81104abc7adf4c83495. So despite being hacky, it's been tried and tested (so much so that code relies on it now x)).
Only the third commit does anything interesting.
It's undesirable to enable `unused_crate_dependencies` with blanket `#![deny(unused)]` due to the amount of redundant `--extern` options passed by Cargo.
Dylan DPC [Fri, 29 May 2020 00:33:26 +0000 (02:33 +0200)]
Rollup merge of #72695 - jclulow:illumos-llvm-catchup, r=nikic
update data layout for illumos x86
In a recent change, 8b199222cc92667cd0e57595ad435cd0a7526af8,
adjustments were made to the data layout we pass to LLVM.
Unfortunately, the illumos target was missed in this change.
See also: https://github.com/rust-lang/rust/pull/67900
Dylan DPC [Fri, 29 May 2020 00:33:24 +0000 (02:33 +0200)]
Rollup merge of #72682 - JohnTitor:mir-tests, r=RalfJung
Add test for #66930
Closes #66930
Closes #67558
They're fixed by #72424.
I skipped adding `--emit=mir` flag to src/test/ui/issues/issue-25145.rs as a regression test since the root cause seems the same and it should be run with `check-pass`, not `run-pass` so we should duplicate that test.
Dylan DPC [Fri, 29 May 2020 00:33:23 +0000 (02:33 +0200)]
Rollup merge of #72674 - Mark-Simulacrum:clippy-always-test-pass, r=oli-obk
Clippy should always build
This just unwraps clippy's build step instead of skipping tests if clippy didn't
build. This matches e.g. cargo's behavior and seems more correct, as we always
expect clippy to successfully build.
I believe this doesn't actually change anything in practice, but I feel mildly uncomfortable potentially leaving this hole open.
Dylan DPC [Fri, 29 May 2020 00:33:11 +0000 (02:33 +0200)]
Rollup merge of #72466 - lzutao:stabilize_str-strip, r=dtolnay
Stabilize str_strip feature
This PR stabilizes these APIs:
```rust
impl str {
/// Returns a string slice with the prefix removed.
///
/// If the string starts with the pattern `prefix`, `Some` is returned with the substring where
/// the prefix is removed. Unlike `trim_start_matches`, this method removes the prefix exactly
/// once.
pub fn strip_prefix<'a, P: Pattern<'a>>(&'a self, prefix: P) -> Option<&'a str>;
/// Returns a string slice with the suffix removed.
///
/// If the string ends with the pattern `suffix`, `Some` is returned with the substring where
/// the suffix is removed. Unlike `trim_end_matches`, this method removes the suffix exactly
/// once.
pub fn strip_suffix<'a, P>(&'a self, suffix: P) -> Option<&'a str>
where
P: Pattern<'a>,
<P as Pattern<'a>>::Searcher: ReverseSearcher<'a>;
}
```
Dylan DPC [Fri, 29 May 2020 00:33:07 +0000 (02:33 +0200)]
Rollup merge of #72239 - hch12907:master, r=dtolnay
Implement PartialOrd and Ord for SocketAddr*
The implementation is mostly the same as the one found in `IpAddr` (other than adding comparison for ports, of course).
Continues #53788 and #53863
Fixes #53710
Joshua M. Clulow [Thu, 28 May 2020 15:09:10 +0000 (08:09 -0700)]
update data layout for illumos x86
In a recent change, 8b199222cc92667cd0e57595ad435cd0a7526af8,
adjustments were made to the data layout we pass to LLVM.
Unfortunately, the illumos target was missed in this change.
See also: https://github.com/rust-lang/rust/pull/67900
bors [Thu, 28 May 2020 00:18:52 +0000 (00:18 +0000)]
Auto merge of #72494 - lcnr:predicate-cleanup, r=nikomatsakis
Pass more `Copy` types by value.
There are a lot of locations where we pass `&T where T: Copy` by reference,
which should both be slightly less performant and less readable IMO.
This PR currently consists of three fairly self contained commits:
- passes `ty::Predicate` by value and stops depending on `AsRef<ty::Predicate>`.
- changes `<&List<_>>::into_iter` to iterate over the elements by value. This would break `List`s
of non copy types. But as the only list constructor requires `T` to be copy anyways, I think
the improved readability is worth this potential future restriction.
- passes `mir::PlaceElem` by value. Mir currently has quite a few copy types which are passed by reference, e.g. `Local`. As I don't have a lot of experience working with MIR, I mostly did this to get some feedback from people who use MIR more frequently
- tries to reuse `ty::Predicate` in case it did not change in some places, which should hopefully
fix the regression caused by #72055
r? @nikomatsakis for the first commit, which continues the work of #72055 and makes adding `PredicateKind::ForAll` slightly more pleasant. Feel free to reassign though
Mark Rousskov [Wed, 27 May 2020 21:25:47 +0000 (17:25 -0400)]
Clippy should always build
This just unwraps clippy's build step instead of skipping tests if clippy didn't
build. This matches e.g. cargo's behavior and seems more correct, as we always
expect clippy to successfully build.
bors [Wed, 27 May 2020 18:31:45 +0000 (18:31 +0000)]
Auto merge of #71996 - Marwes:detach_undo_log, r=nikomatsakis
perf: Revert accidental inclusion of a part of #69218
This was accidentally included in #69464 after a rebase and given
how much `inflate` and `keccak` stresses the obligation forest seems
like a likely culprit to the regression in those benchmarks.
(It is necessary in #69218 as obligation forest needs to accurately
track the root variables or unifications will get lost)
marmeladema [Sun, 24 May 2020 11:18:22 +0000 (12:18 +0100)]
Store `LocalDefId` directly in `rustc_resolve::Resolver` where possible
This commit also include the following changes:
* Remove unused `hir::Map::as_local_node_id` method
* Remove outdated comment about `hir::Map::local_def_id` method
* Remove confusing `GlobMap` type alias
* Use `LocalDefId` instead of `DefId` in `extern_crate_map`
* Use `LocalDefId` instead of `DefId` in `maybe_unused_extern_crates`
* Modify `extern_mod_stmt_cnum` query to accept a `LocalDefId` instead of a `DefId`
Joshua Nelson [Mon, 18 May 2020 00:15:15 +0000 (20:15 -0400)]
Add Peekable::next_if
Prior art:
`rust_analyzer` uses
[`Parser::eat`](https://github.com/rust-analyzer/rust-analyzer/blob/50f4ae798b7c54d417ee88455b87fd0477473150/crates/ra_parser/src/parser.rs#L94), which is `next_if` specialized to
`|y| next_if(|x| x == y)`.
Basically every other parser I've run into in Rust has an equivalent of
Parser::eat; see for example
Dylan DPC [Wed, 27 May 2020 01:09:23 +0000 (03:09 +0200)]
Rollup merge of #72626 - phimuemue:doubleendediter_doc, r=dtolnay
Add remark regarding DoubleEndedIterator
While reviewing https://github.com/rust-itertools/itertools/pull/442/commits/14293bd18f01b6bd4856816222f808f46603eccd#diff-2c16d2ada06ad2fd1fc754679646d471, I realized that a `DoubleEndedIterator` may yield different elements depending on whether it is traversed forwards or backwards. (Not only the *order*, but possibly also the yielded values.)
I found this remarkable, but could not find anything in the current docs, so I thought it may be worth mentioning this explicitly.
Unfortunately, I could not test these changes locally (`rustdoc` complains about `unresolved import`). Sorry if this causes headache.
If I should change something, please let me know. If it seems too trivial, feel free to just close this PR.
Dylan DPC [Wed, 27 May 2020 01:09:15 +0000 (03:09 +0200)]
Rollup merge of #72548 - rossmacarthur:add-mcve-for-50687, r=nikomatsakis
Add test for old compiler ICE when using `Borrow`
The original issue was caused by implementing `Borrow` on a local type and using the tokio-reactor crate which had this impl: https://github.com/tokio-rs/tokio/blob/tokio-0.1.4/tokio-reactor/src/poll_evented.rs#L547-L577
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:554:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.27.0 (3eda71b00 2018-06-19) running on x86_64-apple-darwin
```
Dylan DPC [Wed, 27 May 2020 01:09:12 +0000 (03:09 +0200)]
Rollup merge of #72533 - Diggsey:db-fix-arc-ub2, r=dtolnay
Resolve UB in Arc/Weak interaction (2)
Use raw pointers to avoid making any assertions about the data field.
Follow up from #72479, see that PR for more detail on the motivation.
@RalfJung I was able to avoid a lot of the changes to `Weak`, by making a helper type (`WeakInner`) - because of auto-deref and because the fields have the same name, the rest of the code continues to compile.
bors [Tue, 26 May 2020 23:12:16 +0000 (23:12 +0000)]
Auto merge of #5651 - ebroto:names_as_early_passes, r=flip1995
Register redundant_field_names and non_expressive_names as early passes
Similar names was moved to a pre-expansion pass to solve #2927, so I'm avoiding linting on code from expansion, which makes the dogfood (mostly, see below) pass.
I had to change new_without_default though, and although I understand why it was not triggering before, TBH I don't see why the binding inside the nested `if_chain` is being linted now. Any ideas? (it seems legit though as the code can be changed by the user)
changelog: Register redundant_field_names and non_expressive_names as early passes
Dylan DPC [Tue, 26 May 2020 20:11:34 +0000 (22:11 +0200)]
Rollup merge of #72592 - ehuss:update-books, r=ehuss
Update books
## reference
7 commits in 892b928b565e35d25b6f9c47faee03b94bc41489..becdca9477c9eafa96a4eea5156fe7a2730d9dd2
2020-05-11 11:13:51 -0700 to 2020-05-21 21:08:02 +0100
- Update tuple index token. (rust-lang-nursery/reference#814)
- Fixes minor errors (rust-lang-nursery/reference#818)
- Update that macros can be deprecated. (rust-lang-nursery/reference#813)
- work on char/str descriptions (rust-lang-nursery/reference#809)
- cfg_attr needs a valid predicate (rust-lang-nursery/reference#812)
- Account for removal of UB in float-to-int casts (rust-lang-nursery/reference#810)
- Fix stray plus signs. (rust-lang-nursery/reference#811)
## book
6 commits in 6247be15a7f7509559f7981ee2209b9e0cc121df..e8a4714a9d8a6136a59b8e63544e149683876e36
2020-05-03 10:55:09 -0500 to 2020-05-25 10:29:27 -0500
- code is 1024 now, not 512
- Clean up install a bit
- We don't need build.sh anymore
- Fix CI status in README
- Port to github actions (rust-lang/book#2337)
- operating system -> allocator
## rust-by-example
5 commits in ab072b14393cbd9e8a1d1d75879bf51e27217bbb..7aa82129aa23e7e181efbeb8da03a2a897ef6afc
2020-05-09 08:46:39 -0300 to 2020-05-25 14:54:26 -0300
- Person of age 0 is alive (rust-lang/rust-by-example#1348)
- Gramatical fix in std/rc.md (rust-lang/rust-by-example#1347)
- Capture example should use String (rust-lang/rust-by-example#1331)
- Fix empty bound examples (rust-lang/rust-by-example#1343)
- Fix an inline comment in macros/repeat.md (rust-lang/rust-by-example#1344)
Dylan DPC [Tue, 26 May 2020 20:11:33 +0000 (22:11 +0200)]
Rollup merge of #72581 - samrat:allow-desugared-break-in-labeled-block, r=davidtwco
Allow unlabeled breaks from desugared `?` in labeled blocks
`?` is desugared into a `break` targeting the innermost `try` scope in which it resides. The `break` however will not have a label. https://github.com/rust-lang/rust/blob/master/src/librustc_ast_lowering/expr.rs#L1560
Since the `target` of the `break` is known, the compiler should not complain about an unlabeled jump for `break`s desugared from `?`.
Dylan DPC [Tue, 26 May 2020 20:11:29 +0000 (22:11 +0200)]
Rollup merge of #72342 - jsgf:warn-unused-deps, r=petrochenkov
Warn about unused crate deps
Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`.
Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`.
If a crate has multiple aliases (eg using `foo = { package = "bar" }` in `Cargo.toml`), then it will warn about each unused alias.
This does not consider crate added by some other means than `--extern`, including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this).
Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates, causing spurious warnings. As a result, this lint is "allow" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.
Dylan DPC [Tue, 26 May 2020 20:11:26 +0000 (22:11 +0200)]
Rollup merge of #72294 - GuillaumeGomez:js-cleanup, r=kinnison
JS cleanup
The goal here is just to improve the source code a bit. I recommend to review one commit at a time, otherwise it might not make much sense. :)
The biggest commit is the second one: to prevent to have "global" variables declared in `main.js` (and thus prevent name conflict or overwriting), I moved such code into anonymous functions.
Dylan DPC [Tue, 26 May 2020 20:11:22 +0000 (22:11 +0200)]
Rollup merge of #72270 - RalfJung:lint-ref-to-packed, r=oli-obk
add a lint against references to packed fields
Creating a reference to an insufficiently aligned packed field is UB and should be disallowed, both inside and outside of `unsafe` blocks. However, currently there is no stable alternative (https://github.com/rust-lang/rust/issues/64490) so all we do right now is have a future incompatibility warning when doing this outside `unsafe` (https://github.com/rust-lang/rust/issues/46043).
This adds an allow-by-default lint. @retep998 suggested this can help early adopters avoid issues. It also means we can then do a crater run where this is deny-by-default as suggested by @joshtriplett.
I guess the main thing to bikeshed is the lint name. I am not particularly happy with "packed_references" as it sounds like the packed field has reference type. I chose this because it is similar to "safe_packed_borrows". What about "reference_to_packed" or "unaligned_reference" or so?
bors [Tue, 26 May 2020 17:38:47 +0000 (17:38 +0000)]
Auto merge of #71931 - alexcrichton:reproducible-macos, r=eddyb
Export ZERO_AR_DATE for macos linker invocations
This commit attempts to improve reproducibility of builds on macOS by
exporting the `ZERO_AR_DATE=1` environment variable for all invocations
of the linker. While it looks like this env var is targeted at just the
`ar` command (which does actually read this) it appears that recent-ish
versions of the linker *also* read this environment variable. This
env var forces the linker to set a deterministic zero value for the
mtime in the N_OSO field of the object file.
Currently it's believe that older versions of the linker will simply
ignore this env var, while newer versions will read it and produce a
deterministic output for compilations with debuginfo.
projects / rust.git / log