The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet.
Note: Generally I'm the person who *removes* usages of unstable features from the compiler, not adds more usages of them, but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.
bors [Tue, 19 Oct 2021 11:19:54 +0000 (11:19 +0000)]
Auto merge of #90039 - ehuss:update-cargo, r=ehuss
Update cargo
6 commits in c7957a74bdcf3b11e7154c1a9401735f23ebd484..7fbbf4e8f23e3c24b8afff541dcb17e53eb5ff88
2021-10-11 20:17:07 +0000 to 2021-10-19 02:16:48 +0000
- Make future-incompat-report output more user-friendly (rust-lang/cargo#9953)
- Fix fetching git repos after a force push. (rust-lang/cargo#9979)
- Add rustc-link-args to doctest build (rust-lang/cargo#9916)
- Add the start of a basic benchmarking suite. (rust-lang/cargo#9955)
- Use forms for issue templates. (rust-lang/cargo#9970)
- Add rust_metadata to SerializedPackage (rust-lang/cargo#9967)
bors [Tue, 19 Oct 2021 05:04:38 +0000 (05:04 +0000)]
Auto merge of #90037 - matthiaskrgr:rollup-cdfhxtn, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #89766 (RustWrapper: adapt for an LLVM API change)
- #89867 (Fix macro_rules! duplication when reexported in the same module)
- #89941 (removing TLS support in x86_64-unknown-none-hermitkernel)
- #89956 (Suggest a case insensitive match name regardless of levenshtein distance)
- #89988 (Do not promote values with const drop that need to be dropped)
- #89997 (Add test for issue #84957 - `str.as_bytes()` in a `const` expression)
- #90002 (:arrow_up: rust-analyzer)
- #90034 (Tiny tweak to Iterator::unzip() doc comment example.)
Matthias Krüger [Tue, 19 Oct 2021 03:40:56 +0000 (05:40 +0200)]
Rollup merge of #90034 - moxian:unzip-doc, r=cuviper
Tiny tweak to Iterator::unzip() doc comment example.
It's easier to figure out what it's doing and which output elements map to which input ones if the matrix we are dealing with is rectangular 2x3 rather than square 2x2.
Matthias Krüger [Tue, 19 Oct 2021 03:40:54 +0000 (05:40 +0200)]
Rollup merge of #89988 - tmiasko:unpromote-const-drop, r=oli-obk
Do not promote values with const drop that need to be dropped
Changes from #88558 allowed using `~const Drop` in constants by
introducing a new `NeedsNonConstDrop` qualif.
The new qualif was also used for promotion purposes, and allowed
promotion to happen for values that needs to be dropped but which
do have a const drop impl.
Since for promoted the drop implementation is never executed,
this lead to observable change in behaviour. For example:
```rust
struct Panic();
impl const Drop for Panic {
fn drop(&mut self) {
panic!();
}
}
fn main() {
let _ = &Panic();
}
```
Restore the use of `NeedsDrop` qualif during promotion to avoid the issue.
Matthias Krüger [Tue, 19 Oct 2021 03:40:53 +0000 (05:40 +0200)]
Rollup merge of #89956 - JohnTitor:suggest-case-insensitive-match-names, r=estebank
Suggest a case insensitive match name regardless of levenshtein distance
Fixes #86170
Currently, `find_best_match_for_name` only returns a case insensitive match name depending on a Levenshtein distance. It's a bit unfortunate that that hides some suggestions for typos like `Bar` -> `BAR`. That idea is from https://github.com/rust-lang/rust/pull/46347#discussion_r153701834, but I think it still makes some sense to show a candidate when we find a case insensitive match name as it's more like a typo.
Skipped the `candidate != lookup` check because the current (i.e, `levenshtein_match`) returns the exact same `Symbol` anyway but it doesn't seem to confuse anything on UI tests.
Matthias Krüger [Tue, 19 Oct 2021 03:40:52 +0000 (05:40 +0200)]
Rollup merge of #89941 - hermitcore:kernel, r=joshtriplett
removing TLS support in x86_64-unknown-none-hermitkernel
HermitCore's kernel itself doesn't support TLS. Consequently, the entries in x86_64-unknown-none-hermitkernel should be removed. This commit should help to finalize #89062.
Matthias Krüger [Tue, 19 Oct 2021 03:40:51 +0000 (05:40 +0200)]
Rollup merge of #89867 - Urgau:fix-double-definition, r=GuillaumeGomez
Fix macro_rules! duplication when reexported in the same module
This can append if within the same module a `#[macro_export] macro_rules!`
is declared but also a reexport of itself producing two export of the same
macro in the same module. In that case we only want to document it once.
Before:
```
Module {
is_crate: true,
items: [
Id("0:4"), // pub use crate::repro as repro2;
Id("0:3"), // macro_rules! repro
Id("0:3"), // duplicate, same as above
],
}
```
Matthias Krüger [Tue, 19 Oct 2021 03:40:50 +0000 (05:40 +0200)]
Rollup merge of #89766 - krasimirgg:llvm-14-targetregistrty, r=nagisa
RustWrapper: adapt for an LLVM API change
No functional changes intended.
The LLVM commit
https://github.com/llvm/llvm-project/commit/89b57061f7b769e9ea9bf6ed686e284f3e55affe
moved TargetRegistry.(h|cpp) from Support to MC.
This adapts RustWrapper accordingly.
moxian [Tue, 19 Oct 2021 00:03:51 +0000 (00:03 +0000)]
Tiny tweak to Iterator::unzip() doc comment example.
It's easier to figure out what it's doing and which output
elements map to which input ones if the matrix we are dealing
with is rectangular 2x3 rather than square 2x2.
bors [Mon, 18 Oct 2021 23:02:53 +0000 (23:02 +0000)]
Auto merge of #89229 - oli-obk:i_love_inferctxt, r=jackh726
Remove redundant member-constraint check
impl trait will, for each lifetime in the hidden type, register a "member constraint" that says the lifetime must be equal or outlive one of the lifetimes of the impl trait. These member constraints will be solved by borrowck
But, as you can see in the big red block of removed code, there was an ad-hoc check for member constraints happening at the site where they get registered. This check had some minor effects on diagnostics, but will fall down on its feet with my big type alias impl trait refactor. So we removed it and I pulled the removal out into a (hopefully) reviewable PR that works on master directly.
Tomasz Miąsko [Sun, 17 Oct 2021 00:00:00 +0000 (00:00 +0000)]
Do not promote values with const drop that need to be dropped
Changes from #88558 allowed using `~const Drop` in constants by
introducing a new `NeedsNonConstDrop` qualif.
The new qualif was also used for promotion purposes, and allowed
promotion to happen for values that needs to be dropped but which
do have a const drop impl.
Since for promoted the drop implementation is never executed,
this lead to observable change in behaviour. For example:
```rust
struct Panic();
impl const Drop for Panic {
fn drop(&mut self) {
panic!();
}
}
fn main() {
let _ = &Panic();
}
```
Restore the use of `NeedsDrop` qualif during promotion to avoid the issue.
bors [Mon, 18 Oct 2021 19:53:05 +0000 (19:53 +0000)]
Auto merge of #89124 - cjgillot:owner-info, r=michaelwoerister
Index and hash HIR as part of lowering
Part of https://github.com/rust-lang/rust/pull/88186
~Based on https://github.com/rust-lang/rust/pull/88880 (see merge commit).~
Once HIR is lowered, it is later indexed by the `index_hir` query and hashed for `crate_hash`. This PR moves those post-processing steps to lowering itself. As a side objective, the HIR crate data structure is refactored as an `IndexVec<LocalDefId, Option<OwnerInfo<'hir>>>` where `OwnerInfo` stores all the relevant information for an HIR owner.
The LLVM commit
https://github.com/llvm/llvm-project/commit/89b57061f7b769e9ea9bf6ed686e284f3e55affe
moved TargetRegistry.(h|cpp) from Support to MC.
This adapts RustWrapper accordingly.
Matthias Krüger [Mon, 18 Oct 2021 06:13:27 +0000 (08:13 +0200)]
Rollup merge of #89974 - est31:let_else_if_error, r=nagisa
Nicer error message if the user attempts to do let...else if
Gives a nice "conditional `else if` is not supported for `let...else`" error when encountering a `let...else if` pattern, as suggested in the [let...else tracking issue](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205).
Matthias Krüger [Mon, 18 Oct 2021 06:13:25 +0000 (08:13 +0200)]
Rollup merge of #89950 - infinity0:master, r=Mark-Simulacrum
bootstrap: tweak verbosity settings
Currently the verbosity settings are:
- 2: RUSTC-SHIM envvars get spammed on every invocation, O(30) lines
cargo is passed -v which outputs CLI invocations, O(5) lines
- 3: cargo is passed -vv which outputs build script output, O(0-10) lines
This commit changes it to:
- 1: cargo is passed -v, O(5) lines
- 2: cargo is passed -vv, O(10) lines
- 3: RUSTC-SHIM envvars get spammed, O(30) lines
bors [Sun, 17 Oct 2021 22:29:31 +0000 (22:29 +0000)]
Auto merge of #89499 - Mark-Simulacrum:with-llvm-13, r=nikic
Split out LLVM PGO step and use clang 13 to compile LLVM
We're seeing a PGO version mismatch error in CI logs:
LLVM Profile Error: Runtime and instrumentation version mismatch : expected 5, but get 7
which is likely due to the version bumped here differing from that used by
rustc.
This PR fixes this by splitting out the PGO step for LLVM into a separate phase of the pgo.sh script, which nets no change to performance (see [these results](https://perf.rust-lang.org/compare.html?start=c34ac8747ca96d09cb08b8f5adddead826e77c06&end=e272c2af45f40c74dab83948235903ffbe3ad57f)). Then, it follows that up with an upgrade to LLVM/clang version 13 as our bootstrap compiler, which yields the performance improvements for this PR -- around 5%. This depends on the first step here, because otherwise we end up somehow clobbering or otherwise hurting our ability to effectively collect performance data, yielding reductions in performance for a subset of benchmarks -- it is not clear what the cause here was precisely, but the split only costs ~10 minutes and seems worthwhile.
bors [Sun, 17 Oct 2021 19:18:18 +0000 (19:18 +0000)]
Auto merge of #89984 - matthiaskrgr:rollup-ikmyhmx, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #89738 (ty::pretty: prevent infinite recursion for `extern crate` paths.)
- #89888 (Make `llvm.download-ci-llvm="if-available"` work for tier 2 targets with host tools)
- #89945 (Remove a mention to `copy_from_slice` from `clone_from_slice` doc)
- #89946 (Fix an ICE with TAITs and Future)
- #89963 (Some "parenthesis" and "parentheses" fixes)
- #89975 (Add a regression test for #85921)
- #89977 (Make Result::as_mut const)
Matthias Krüger [Sun, 17 Oct 2021 16:18:59 +0000 (18:18 +0200)]
Rollup merge of #89963 - r00ster91:parenthesisparentheses, r=nagisa
Some "parenthesis" and "parentheses" fixes
"Parenthesis" is the singular (e.g. one `(` or one `)`) and "parentheses" is the plural (multiple `(` or `)`s) and this is not hard to mix up so here are some fixes for that.
Matthias Krüger [Sun, 17 Oct 2021 16:18:56 +0000 (18:18 +0200)]
Rollup merge of #89888 - rusticstuff:download-ci-llvm-apple-arm64, r=Mark-Simulacrum
Make `llvm.download-ci-llvm="if-available"` work for tier 2 targets with host tools
`llvm.download-ci-llvm="if-available"` is used for most profiles configured via `x.py setup`. It allows downloading prebuilt LLVM tarballs from the CI artifacts for a configured list of platforms. Currently this list is restricted to tier 1 targets but it makes sense for all tier 2 targets with host tools.
Matthias Krüger [Sun, 17 Oct 2021 16:18:55 +0000 (18:18 +0200)]
Rollup merge of #89738 - eddyb:extern-crate-recursion, r=nagisa
ty::pretty: prevent infinite recursion for `extern crate` paths.
Fixes #55779, fixes #87932.
This fix is based on `@estebank's` idea in https://github.com/rust-lang/rust/issues/55779#issuecomment-614758510 - but instead of trying to get `try_print_visible_def_path_recur`'s cycle detection to work in this case, this PR "just" disables the "visible path" feature when printing the path to an `extern crate`, so that the old recursion chain of `try_print_visible_def_path -> print_def_path -> try_print_visible_def_path`, is now impossible.
Both tests have been confirmed to crash `rustc` because of a stack overflow, without the fix.
bors [Sun, 17 Oct 2021 12:33:12 +0000 (12:33 +0000)]
Auto merge of #89514 - davidtwco:polymorphize-shims-and-predicates, r=lcnr
polymorphization: shims and predicates
Supersedes #75737 and #75414. This pull request includes up some changes to polymorphization which hadn't landed previously and gets stage2 bootstrapping and the test suite passing when polymorphization is enabled. There are still issues with `type_id` and polymorphization to investigate but this should get polymorphization in a reasonable state to work on.
- #75737 and #75414 both worked but were blocked on having the rest of the test suite pass (with polymorphization enabled) with and without the PRs. It makes more sense to just land these so that the changes are in.
- #75737's changes remove the restriction of `InstanceDef::Item` on polymorphization, so that shims can now be polymorphized. This won't have much of an effect until polymorphization's analysis is more advanced, but it doesn't hurt.
- #75414's changes remove all logic which marks parameters as used based on their presence in predicates - given #75675, this will enable more polymorphization and avoid the symbol clashes that predicate logic previously sidestepped.
- Polymorphization now explicitly checks (and skips) foreign items, this is necessary for stage2 bootstrapping to work when polymorphization is enabled.
- The conditional determining the emission of a note adding context to a post-monomorphization error has been modified. Polymorphization results in `optimized_mir` running for shims during collection where that wouldn't happen previously, some errors are emitted during `optimized_mir` and these were considered post-monomorphization errors with the existing logic (more errors and shims have a `DefId` coming from the std crate, not the local crate), adding a note that resulted in tests failing. It isn't particularly feasible to change where polymorphization runs or prevent it from using `optimized_mir`, so it seemed more reasonable to not change the conditional.
- `characteristic_def_id_of_type` was being invoked during partitioning for self types of impl blocks which had projections that depended on the value of unused generic parameters of a function - this caused a ICE in a debuginfo test. If partitioning is enabled and the instance needs substitution then this is skipped. That test still fails for me locally, but not with an ICE, but it fails in a fresh checkout too, so 🤷♂️.
bors [Sun, 17 Oct 2021 09:30:30 +0000 (09:30 +0000)]
Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic, r=yaahc
linux/aarch64 Now() should be actually_monotonic()
While issues have been seen on arm64 platforms the Arm architecture requires
that the counter monotonically increases and that it must provide a uniform
view of system time (e.g. it must not be possible for a core to receive a
message from another core with a time stamp and observe time going backwards
(ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have
bugs (#49281, #56940) which cause time to not monotonically increase, these have
been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those
who refuse to update their kernels:
SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1
FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10
HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11
ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12
255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around
this problem and a small test program using glommio shows the majority of time spent
acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this, but actually
makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop)
for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock
and because of how the load/store-exclusives scale on large Arm systems is both unfair
to threads and tends to go backwards in performance.
A small sample program using glommio improves by 70x on a 32 core Graviton2
system with this change.
bors [Sun, 17 Oct 2021 06:27:08 +0000 (06:27 +0000)]
Auto merge of #89968 - JohnTitor:rollup-z51n967, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #89507 (Add `#[repr(i8)]` to `Ordering`)
- #89849 (CI: Selecting the Xcode version no longer needed with the macos-11 runners.)
- #89886 (Update the wasi-libc built with the wasm32-wasi target)
- #89907 (Remove FIXME since there is nothing to be fixed)
- #89943 (clippy::complexity fixes)
- #89953 (Make Option::as_mut const)
- #89958 (Correct small typo)
Yuki Okushi [Sat, 16 Oct 2021 22:52:18 +0000 (07:52 +0900)]
Rollup merge of #89886 - alexcrichton:update-wasi-libc, r=kennytm
Update the wasi-libc built with the wasm32-wasi target
This commit updates the wasi-libc that we include with the wasm32-wasi
target, which brings in various misc fixes such as musl updates and some
math tweaks.
Yuki Okushi [Sat, 16 Oct 2021 22:52:18 +0000 (07:52 +0900)]
Rollup merge of #89849 - rusticstuff:remove-xcode-select, r=Mark-Simulacrum
CI: Selecting the Xcode version no longer needed with the macos-11 runners.
It does nothing nowadays since `/Applications/Xcode_12.2.app` does not exist in the GH runner environment and
automatically using the latest version selected by the GH environment is better anyway.
bors [Sat, 16 Oct 2021 18:20:20 +0000 (18:20 +0000)]
Auto merge of #89860 - camsteffen:macro-semi, r=petrochenkov
Remove trailing semicolon from macro call span
Macro call site spans are now less surprising/more consistent since they no longer contain a semicolon after the macro call.
The downside is that we need to do a little guesswork to get the semicolon in diagnostics. But this should not be noticeable since it is rare for the semicolon to not immediately follow the macro call.
Ximin Luo [Sat, 16 Oct 2021 12:30:24 +0000 (13:30 +0100)]
bootstrap: tweak verbosity settings
Currently the verbosity settings are:
- 2: RUSTC-SHIM envvars get spammed on every invocation, O(30) lines
cargo is passed -v which outputs CLI invocations, O(5) lines
- 3: cargo is passed -vv which outputs build script output, O(0-10) lines
This commit changes it to:
- 1: cargo is passed -v, O(5) lines
- 2: cargo is passed -vv, O(10) lines
- 3: RUSTC-SHIM envvars get spammed, O(30) lines
Stefan Lankes [Sat, 16 Oct 2021 07:41:59 +0000 (09:41 +0200)]
HermitCore's kernel itself doesn't support TLS
HermitCore's kernel itself doesn't support TLS.
Consequently, the entries in x86_64-unknown-none-hermitkernel should be removed.
This commit should help to finalize #89062.
bors [Sat, 16 Oct 2021 06:31:40 +0000 (06:31 +0000)]
Auto merge of #89939 - matthiaskrgr:rollup-q3lrdck, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #89509 (Stabilize `unreachable_unchecked` as `const fn`)
- #89898 (Remove alloc::prelude)
- #89902 (Restrict the aarch64 outline atomics test to Linux)
- #89906 (Moved format-version constant to rustdoc-json-types)
- #89912 (emitter: current substitution can be multi-line)
- #89914 (Emit impl difference error for GenericBoundFailure too)
- #89915 (Some outlives cleanup)
- #89918 (Add some GATs related regression tests)
- #89921 ([fuchsia] Update process info struct)
- #89925 (updating docs to mention usage of AtomicBool)
Matthias Krüger [Sat, 16 Oct 2021 06:02:27 +0000 (08:02 +0200)]
Rollup merge of #89921 - joshuaseaton:zircon-process, r=tmandry
[fuchsia] Update process info struct
The fuchsia platform is in the process of softly transitioning over to
using a new value for ZX_INFO_PROCESS with a new corresponding struct.
This change migrates libstd.
See [fxrev.dev/510478](https://fxrev.dev/510478) and [fxbug.dev/30751](https://fxbug.dev/30751) for more detail.
Matthias Krüger [Sat, 16 Oct 2021 06:02:24 +0000 (08:02 +0200)]
Rollup merge of #89912 - davidtwco:issue-89280-split-lines-multiple-lines, r=oli-obk
emitter: current substitution can be multi-line
Fixes #89280.
In `splice_lines`, there is some arithmetic to compute the required alignment such that future substitutions in a suggestion are aligned correctly. However, this assumed that the current substitution's span was only on a single line. In circumstances where this was not true, it could result in a arithmetic overflow when the substitution's end column was less than the substitution's start column.
Matthias Krüger [Sat, 16 Oct 2021 06:02:22 +0000 (08:02 +0200)]
Rollup merge of #89902 - rusticstuff:outline-atomics-linux-only, r=workingjubilee
Restrict the aarch64 outline atomics test to Linux
The test was introduced in #83655, which enables the `outline-atomics` feature for aarch64-unknown-linux-* but not for any other aarch64 targets. The test did not check for Linux causing test failures on aarch64-apple-darwin.
Matthias Krüger [Sat, 16 Oct 2021 06:02:20 +0000 (08:02 +0200)]
Rollup merge of #89509 - jhpratt:stabilize-const_unreachable_unchecked, r=oli-obk
Stabilize `unreachable_unchecked` as `const fn`
Closes #53188
This PR stabilizes `core::hint::unreachable_unchecked` as `const fn`. MIRI is able to detect when this method is called. Stabilization was delayed until `const_panic` was stabilized so as to avoid users calling this method in its place (thus resulting in runtime UB). With #89508, that is no longer an issue.
est31 [Sat, 16 Oct 2021 02:37:30 +0000 (04:37 +0200)]
Update the syn crate and adopt let_else in three more places
The syn crate has gained support for let_else syntax in version 1.0.76,
see https://github.com/dtolnay/syn/pull/1057 .
In the three instances that use let_else, we've sent code through an
attr macro, which would create compile errors when there was no
let_else support in syn. To avoid this, we ran
`cargo +nightly update -p syn` for updating the syn crate.
bors [Fri, 15 Oct 2021 22:31:53 +0000 (22:31 +0000)]
Auto merge of #85379 - mdaverde:uds-abstract, r=joshtriplett
Add abstract namespace support for Unix domain sockets
Hello! The other day I wanted to mess around with UDS in Rust and found that abstract namespaces ([unix(7)](https://man7.org/linux/man-pages/man7/unix.7.html)) on Linux still needed development. I took the approach of adding `_addr` specific public functions to reduce conflicts.
Feature name: `unix_socket_abstract`
Tracking issue: #85410
Further context: #42048
```rust
#![feature(unix_socket_abstract)]
use std::os::unix::net::{UnixListener, SocketAddr};
fn main() -> std::io::Result<()> {
let addr = SocketAddr::from_abstract_namespace(b"namespace")?; // Linux only
let listener = match UnixListener::bind_addr(&addr) {
Ok(sock) => sock,
Err(err) => {
println!("Couldn't bind: {:?}", err);
return Err(err);
}
};
Ok(())
}
```
## Further Details
The main inspiration for the implementation came from the [nix-rust](https://github.com/nix-rust/nix/blob/master/src/sys/socket/addr.rs#L558) crate but there are also other [historical](https://github.com/rust-lang/rust/commit/c4db0685b181f12c4285dac3d932f1859bba74f5) [attempts](https://github.com/tormol/uds/blob/master/src/addr.rs#L324) with similar approaches.
A comment I did have was with this change, we now allow a `SocketAddr` to be constructed explicitly rather than just used almost as a handle for the return of `peer_addr` and `local_addr`. We could consider adding other explicit constructors (e.g. `SocketAddr::from_pathname`, `SockerAddr::from_unnamed`).
projects / rust.git / log