bors [Thu, 4 Feb 2021 23:16:08 +0000 (23:16 +0000)]
Auto merge of #81761 - m-ou-se:rollup-xp7v07n, r=m-ou-se
Rollup of 9 pull requests
Successful merges:
- #74304 (Stabilize the Wake trait)
- #79805 (Rename Iterator::fold_first to reduce and stabilize it)
- #81556 (introduce future-compatibility warning for forbidden lint groups)
- #81645 (Add lint for `panic!(123)` which is not accepted in Rust 2021.)
- #81710 (OsStr eq_ignore_ascii_case takes arg by value)
- #81711 (add #[inline] to all the public IpAddr functions)
- #81725 (Move test to be with the others)
- #81727 (Revert stabilizing integer::BITS.)
- #81745 (Stabilize poison API of Once, rename poisoned())
bors [Thu, 4 Feb 2021 20:30:11 +0000 (20:30 +0000)]
Auto merge of #81762 - pietroalbini:fix-install-msys2, r=m-ou-se
CI: only copy python.exe to python3.exe if the latter does not exist
We're copying the binary to make sure we can call `python3.exe` around, but it seems like the base image of GitHub Actions changed, copying the file before we do so. This PR changes the CI script to only copy the file if it doesn't already exist.
Pietro Albini [Thu, 4 Feb 2021 20:24:41 +0000 (21:24 +0100)]
ci: only copy python.exe to python3.exe if the latter does not exist
We're copying the binary to make sure we can call python3.exe around,
but it seems like the base image of GitHub Actions changed, copying the
file before we do so.
This commit changes the CI script to only copy the file if it doesn't
already exist.
Mara Bos [Thu, 4 Feb 2021 20:10:44 +0000 (21:10 +0100)]
Rollup merge of #81745 - Kixunil:stabilize_once_poison, r=m-ou-se
Stabilize poison API of Once, rename poisoned()
This stabilizes:
* `OnceState`
* `OnceState::is_poisoned()` (previously named `poisoned()`)
* `Once::call_once_force()`
`poisoned()` was renamed because the new name is more clear as a few
people agreed and nobody objected.
Closes #33577
Notes:
* I'm not entirely sure it's supposed to be 1.51, LMK if I did it wrong
* I failed to run tests locally, so we will have to leave it to bors or someone else can try
Mara Bos [Thu, 4 Feb 2021 20:10:42 +0000 (21:10 +0100)]
Rollup merge of #81727 - m-ou-se:unstabilize-bits, r=Mark-Simulacrum
Revert stabilizing integer::BITS.
We agreed in the libs meeting just now to revert stablization, since the [breakage](https://github.com/rust-lang/rust/issues/81654) is significant throughout the ecosystem, through `lexical-core`.
Mara Bos [Thu, 4 Feb 2021 20:10:37 +0000 (21:10 +0100)]
Rollup merge of #81710 - TyPR124:patch-2, r=m-ou-se
OsStr eq_ignore_ascii_case takes arg by value
Per a comment on #70516 this changes `eq_ignore_ascii_case` to take the generic parameter `S: AsRef<OsStr>` by value instead of by reference.
This is technically a breaking change to an unstable method. I think the only way it would break is if you called this method with an explicit type parameter, ie `my_os_str.eq_ignore_ascii_case::<str>("foo")` becomes `my_os_str.eq_ignore_ascii_case::<&str>("foo")`.
Besides that, I believe it is overall more flexible since it can now take an owned `OsString` for example.
If this change should be made in some other PR (like #80193) then please just close this.
Mara Bos [Thu, 4 Feb 2021 20:10:36 +0000 (21:10 +0100)]
Rollup merge of #81645 - m-ou-se:panic-lint, r=estebank,flip1995
Add lint for `panic!(123)` which is not accepted in Rust 2021.
This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021.
It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.
It renames the lint to `non_fmt_panic` to match the lint naming guidelines.
Mara Bos [Thu, 4 Feb 2021 20:10:34 +0000 (21:10 +0100)]
Rollup merge of #81556 - nikomatsakis:forbidden-lint-groups-lint, r=pnkfelix
introduce future-compatibility warning for forbidden lint groups
We used to ignore `forbid(group)` scenarios completely. This changed in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.
Mara Bos [Thu, 4 Feb 2021 20:10:33 +0000 (21:10 +0100)]
Rollup merge of #79805 - m-ou-se:iterator-reduce, r=KodrAus
Rename Iterator::fold_first to reduce and stabilize it
This stabilizes `#![feature(iterator_fold_self)]`.
The name for this function (originally `fold_first`) was still an open question, but the discussion on [the tracking issue](https://github.com/rust-lang/rust/issues/68125) seems to have converged to `reduce`.
Mara Bos [Thu, 4 Feb 2021 20:10:31 +0000 (21:10 +0100)]
Rollup merge of #74304 - yoshuawuyts:stabilize-wake, r=KodrAus
Stabilize the Wake trait
This PR proposes stabilizing the `wake_trait` feature, tracking issue https://github.com/rust-lang/rust/issues/69912.
## Motivation
The surface area this trait introduces is small, and it has been on nightly for 4 months without any reported issues. Given the surface area of this trait is small and only serves to provide a safe interface around the already stable [`std::task::RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWaker.html) it seems unlikely this trait will require any further changes. So I'm proposing we stabilize this.
Personally I would love to have this available on stable, since it would enable cleaning up some runtime internals by removing the tedious pointer required to construct a [`RawWakerVTable`](https://doc.rust-lang.org/std/task/struct.RawWakerVTable.html). I believe the intent was always to introduce a `Wake` counterpart to `RawWaker` in order to safely construct `Waker` instances. And the `Wake` trait feels like it does that job as intended.
## Implementation notes
This PR itself fixes a link in the docs, and introduces an example of how to use the trait: a minimal `block_on` example that runs a future to completion on the current thread. It doesn't include fancier features such as support for nesting, but is intended to serve as a teaching device for both `task::Wake` and futures alike.
Mara Bos [Mon, 1 Feb 2021 21:30:09 +0000 (22:30 +0100)]
Add lint for `panic!(123)` which is not accepted in Rust 2021.
This extends the `panic_fmt` lint to warn for all cases where the first
argument cannot be interpreted as a format string, as will happen in
Rust 2021.
It suggests to add `"{}", ` to format the message as a string. In the
case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.
It renames the lint to `non_fmt_panic` to match the lint naming
guidelines.
Mara Bos [Wed, 3 Feb 2021 17:51:17 +0000 (18:51 +0100)]
Rollup merge of #81715 - jryans:tab-handling-ice-81614, r=estebank
Reduce tab formatting assertions to debug only
The tab replacement for diagnostics added in #79757 included a few assertions to ensure all tab characters are handled appropriately. We've started getting reports of these assertions firing (#81614). Since it's only a cosmetic issue, this downgrades the assertions to debug only, so we at least continue compiling even if the diagnostics might be a tad wonky.
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Mara Bos [Wed, 3 Feb 2021 17:51:12 +0000 (18:51 +0100)]
Rollup merge of #80394 - RalfJung:const-err-future, r=oli-obk
make const_err a future incompat lint
This is the first step for https://github.com/rust-lang/rust/issues/71800: make const_err a future-incompat lint. I also rewrote the const_err lint description as the old one seemed wrong.
This has the unfortunate side-effect of making const-eval error even more verbose by making the const_err message longer without fixing the redundancy caused by additionally emitting an error on each use site of the constant. We cannot fix that redundancy until const_err is a *hard* error (at that point the error-on-use-site can be turned into a `delay_span_bug!` for uses of monomorphic consts, and into a nicely rendered error for [lazily / post-monomorhization evaluated] associated consts).
~~The one annoying effect of this PR is that `let _x = &(1/(1-1));` now also shows the future-incompat warning, even though of course we will *not* make this a hard error. We'll instead (hopefully) stop promoting it -- see https://github.com/rust-lang/rfcs/pull/3027. The only way I see to avoid the future-incompat warning is to use a different lint for "failure to evaluate promoted".~~
The tab replacement for diagnostics added in #79757 included a few assertions to
ensure all tab characters are handled appropriately. We've started getting
reports of these assertions firing (#81614). Since it's only a cosmetic issue,
this downgrades the assertions to debug only, so we at least continue compiling
even if the diagnostics might be a tad wonky.
Before this change it would ICE. In #70998 the removed logic was added
to provide better suggestions, and the `delay_span_bug` guard was added
to protect against a potential logic error when returning traits. As it
happens, there are cases, like the one above, where traits can indeed be
returned, so valid code was being rejected.
Tyler Ruckinger [Wed, 3 Feb 2021 15:28:51 +0000 (10:28 -0500)]
OsStr eq_ignore_ascii_case takes arg by value
Per a comment on #70516 this changes `eq_ignore_ascii_case` to take the generic parameter `S: AsRef<OsStr>` by value instead of by reference.
This is technically a breaking change to an unstable method. I think the only way it would break is if you called this method with an explicit type parameter, ie `my_os_str.eq_ignore_ascii_case::<str>("foo")` becomes `my_os_str.eq_ignore_ascii_case::<&str>("foo")`.
Besides that, I believe it is overall more flexible since it can now take an owned `OsString` for example.
If this change should be made in some other PR (like #80193) then please just close this.
bors [Wed, 3 Feb 2021 08:59:27 +0000 (08:59 +0000)]
Auto merge of #81694 - GuillaumeGomez:rollup-odg6xqi, r=GuillaumeGomez
Rollup of 4 pull requests
Successful merges:
- #81144 (Fixed formatting typo in map_while docs)
- #81573 (Add some links to the cell docs.)
- #81679 (Bind all clean::Type variants and remove FIXME)
- #81681 (Better styling of "Switch result tab" shortcut)
bors [Wed, 3 Feb 2021 06:00:43 +0000 (06:00 +0000)]
Auto merge of #81346 - hug-dev:nonsecure-call-abi, r=jonas-schievink
Add a new ABI to support cmse_nonsecure_call
This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call.
See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928).
This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃
I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now).
On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
bors [Wed, 3 Feb 2021 03:03:08 +0000 (03:03 +0000)]
Auto merge of #81535 - nikic:update-test-various, r=sanxiyn
Update test-various to Ubuntu 20.04
The test command-setgroups.rs is adjusted to skip on musl, where `sysconf(_SC_NGROUPS_MAX)` always returns a dummy value of 32, even though the actual value is 65536. I'm not sure why this only became a problem now, as the information I found indicates that this value changed in kernel version 2.6.4, which is ages ago.
I'm a bit unsure whether this one will go through, because I locally also saw a failure in std-backtrace.rs which went away on subsequent runs, and also had port assignment failures, but I think those might be on my side. I'm kind of curious how the code in https://github.com/rust-lang/rust/blob/b122908617436af187252572ed5db96850551380/library/std/src/net/test.rs#L43-L56 is supposed to work, as the directory names it checks don't seem to appear anywhere else.
Niko Matsakis [Sat, 30 Jan 2021 00:06:00 +0000 (19:06 -0500)]
introduce future-compatibility warning for forbidden lint groups
We used to ignore `forbid(group)` scenarios completely. This changed
in #78864, but that led to a number of regressions (#80988, #81218).
This PR introduces a future compatibility warning for the case where
a group is forbidden but then an individual lint within that group
is allowed. We now issue a FCW when we see the "allow", but permit
it to take effect.
bors [Tue, 2 Feb 2021 23:15:22 +0000 (23:15 +0000)]
Auto merge of #81678 - jackh726:rollup-3nerni4, r=jackh726
Rollup of 14 pull requests
Successful merges:
- #80593 (Upgrade Chalk)
- #81260 (Add .editorconfig)
- #81455 (Add AArch64 big-endian and ILP32 targets)
- #81517 (Remove remnants of the santizer runtime crates from bootstrap)
- #81530 (sys: use `process::abort()` instead of `arch::wasm32::unreachable()`)
- #81544 (Add better diagnostic for unbounded Abst. Const)
- #81588 (Add doc aliases for "delete")
- #81603 (rustbuild: Don't build compiler twice for error-index-generator.)
- #81634 (Add long explanation e0521)
- #81636 (Directly use `Option<&[T]>` instead of converting from `Option<&Vec<T>>` later on)
- #81647 (Fix bug with assert!() calling the wrong edition of panic!().)
- #81655 (Improve wording of suggestion about accessing field)
- #81665 (Fix out of date `Scalar` documentation)
- #81671 (Add more associated type tests)
Jack Huey [Tue, 2 Feb 2021 21:01:48 +0000 (16:01 -0500)]
Rollup merge of #81655 - matsujika:suggest-accessing-field-rewording, r=estebank
Improve wording of suggestion about accessing field
Follow-up to #81504
The compiler at this moment suggests "you might have meant to use field `b` of type `B`", sounding like it's type `B` which has the field `b`.
r? ```@estebank```
Jack Huey [Tue, 2 Feb 2021 21:01:42 +0000 (16:01 -0500)]
Rollup merge of #81603 - ehuss:error-index-build, r=Mark-Simulacrum
rustbuild: Don't build compiler twice for error-index-generator.
When using `--stage=1`, the error-index-generator was forcing the compiler to be built twice. This isn't necessary; the error-index-generator just needs the same unusual logic that rustdoc uses to build with stage minus one.
`--stage=0` and `--stage=2` should be unaffected by this change.
Jack Huey [Tue, 2 Feb 2021 21:01:39 +0000 (16:01 -0500)]
Rollup merge of #81544 - JulianKnodt:sat_where, r=lcnr
Add better diagnostic for unbounded Abst. Const
~~In the case where a generic abst. const requires a trivial where bound: `where TypeWithConst<const_fn(N)>: ,`,
instead of requiring a where bound, just check that only consts are being substituted in to skip over where check.~~
~~This is pretty sketchy, but I think it works. Presumably, if there is checking for type bounds added later, it can first check nested requirements, and see if they're satisfied by the current `ParamEnv`.~~
Changed the diagnostic to add a better example, which is more practical than what was previously proposed.
Jack Huey [Tue, 2 Feb 2021 21:01:38 +0000 (16:01 -0500)]
Rollup merge of #81530 - ojeda:sys-use-abort-instead-of-wasm32-unreachable, r=Mark-Simulacrum
sys: use `process::abort()` instead of `arch::wasm32::unreachable()`
Rationale:
- `abort()` lowers to `wasm32::unreachable()` anyway.
- `abort()` isn't `unsafe`.
- `abort()` matches the comment better.
- `abort()` avoids confusion by future readers (e.g. https://github.com/rust-lang/rust/pull/81527): the naming of wasm's `unreachable` instruction is a bit unfortunate because it is not related to the `unreachable()` intrinsic (intended to trigger UB).
Codegen is likely to be different since `unreachable()` is `inline` while `abort()` is `cold`. Since it doesn't look like we are expecting here to trigger this case, the latter seems better anyway.
Jack Huey [Tue, 2 Feb 2021 21:01:33 +0000 (16:01 -0500)]
Rollup merge of #81260 - vn971:restore-editorconfig, r=Mark-Simulacrum
Add .editorconfig
This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.
Jack Huey [Tue, 2 Feb 2021 21:01:33 +0000 (16:01 -0500)]
Rollup merge of #81260 - vn971:restore-editorconfig, r=Mark-Simulacrum
Add .editorconfig
This adds a .editorconfig file to rust-lang/rust, matching Clippy's. It's not clear that this will benefit many people, but the cost is low and the rewards are potentially meaningful.
Jack Huey [Tue, 2 Feb 2021 21:01:32 +0000 (16:01 -0500)]
Rollup merge of #80593 - jackh726:chalk-upgrade, r=nikomatsakis
Upgrade Chalk
~~Blocked on rust-lang/chalk#670~~
~~Now blocked on rust-lang/chalk#680 and release~~
In addition to the straight upgrade, I also tried to fix some tests by properly returning variables and max universes in the solution. Unfortunately, this actually triggers the same perf problem that rustc traits code runs into in `canonicalizer`. Not sure what the root cause of this problem is, or why it's supposed to be solved in chalk.
bors [Tue, 2 Feb 2021 20:27:09 +0000 (20:27 +0000)]
Auto merge of #81541 - Aaron1011:early-lint-async-fn, r=petrochenkov
Fix early lints inside an async desugaring
Fixes #81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the NodeId of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that NodeId does not actually exist in the AST.
This commit uses the parent of a desugared closure when computing
`lint_node_id`, which is something that actually exists in the AST (an
`async fn` or async closure).
Aaron Hill [Sat, 30 Jan 2021 00:03:20 +0000 (19:03 -0500)]
Fix early lints inside an async desugaring
Fixes #81531
When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the `NodeId` of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that `NodeId` does not actually exist in the AST.
This commit explicitly calls `check_lint` for the `NodeId`s of closures
desugared from async expressions, ensuring that we do not miss any
buffered lints.
bors [Tue, 2 Feb 2021 18:05:35 +0000 (18:05 +0000)]
Auto merge of #6639 - xFrednet:0000-configuration-documentation-some-nits, r=flip1995
Updated some NITs in the documentation from #6630
I've implemented the two suggestions from #6630 that were added after the merge. This PR also changes the example code to use `register_*_pass` instead of `register_late_pass`. I'm not sure if this is better or worse, but it makes it clearer in my opinion. Let me know if I should change it back.
Vasili Novikov [Fri, 22 Jan 2021 08:51:23 +0000 (09:51 +0100)]
Add .editorconfig
Editorconfig is a lightweight specification that
helps maintaining consistent coding/formatting style
accross editors, especially those editors
that are not explicitly aware of Rust and rustfmt.
Vasili Novikov [Fri, 22 Jan 2021 08:51:23 +0000 (09:51 +0100)]
Add .editorconfig
Editorconfig is a lightweight specification that
helps maintaining consistent coding/formatting style
accross editors, especially those editors
that are not explicitly aware of Rust and rustfmt.
bors [Tue, 2 Feb 2021 15:37:24 +0000 (15:37 +0000)]
Auto merge of #6523 - brightly-salty:missing-panic-doc, r=flip1995
Add new lint "missing_panics_doc"
fixes #1974
changelog: Added the "missing_panics_doc" lint which lints when public functions that may panic are missing "# Panics" in their doc comment
```
warning: returning the result of a `let` binding from a block
--> src/main.rs:24:5
|
23 | let value = Foo::new(&x).value();
| --------------------------------- unnecessary `let` binding
24 | value
| ^^^^^
|
= note: `#[warn(clippy::let_and_return)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_and_return
help: return the expression directly
|
23 |
24 | Foo::new(&x).value()
|
```
Implementing the suggested fix, removing the temporary let binding,
yields a compiler error:
```
error[E0597]: `x` does not live long enough
--> src/main.rs:23:14
|
23 | Foo::new(&x).value()
| ---------^^-
| | |
| | borrowed value does not live long enough
| a temporary with access to the borrow is created here ...
24 | }
| -
| |
| `x` dropped here while still borrowed
| ... and the borrow might be used here, when that temporary is dropped and runs the `Drop` code for type `Foo`
|
= note: the temporary is part of an expression at the end of a block;
consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
|
23 | let x = Foo::new(&x).value(); x
| ^^^^^^^ ^^^
```
The fix:
Of course, clippy looks like it should already handle this edge case;
however, it appears `utils::fn_def_id` is not returning a `DefId` for
`Foo::new`. Changing the `qpath_res` lookup to use the child Path
`hir_id` instead of the parent Call `hir_id` fixes the issue.
Hugues de Valon [Sun, 24 Jan 2021 17:15:05 +0000 (17:15 +0000)]
Add a new ABI to support cmse_nonsecure_call
This commit adds a new ABI to be selected via `extern
"C-cmse-nonsecure-call"` on function pointers in order for the compiler to
apply the corresponding cmse_nonsecure_call callsite attribute.
For Armv8-M targets supporting TrustZone-M, this will perform a
non-secure function call by saving, clearing and calling a non-secure
function pointer using the BLXNS instruction.
See the page on the unstable book for details.
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>