submodules: update cargo from f534844c2 to cb06cb269
Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````
I'd like to get the fix for https://github.com/rust-lang/cargo/issues/8223 into nightly asap.
r? @ehuss
x.py: allow configuring the build directory
This allows configuring the directory for build artifacts, instead of having it always be `./build`. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.
The configuration lives in `config.toml` under `build.build-dir`. By default, it keeps the existing default of `./build`, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using `$ROOT`.
r? @Mark-Simulacrum
Shrink `LocalDecl`
`LocalDecl` contributes 4-8% of peak heap memory usage on a range of benchmarks. This PR reduces its size from 128 bytes to 56 bytes on 64-bit, and does some clean-ups as well.
r? @matthewjasper
Add core::future::{pending,ready}
Adds two future constructors to `core`: `future::ready` and `future::pending`. These functions enable constructing futures of any type that either immediately resolve, or never resolve which is an incredible useful tool when writing documentation.
These functions have prior art in both the `futures` and `async-std` crates. This implementation has been adapted from the `futures` crate.
## Examples
In https://github.com/rust-lang/rust/pull/70817 we propose adding the `ready!` macro. In the example we use an `async fn` which does not return a future that implements `Unpin`, which leads to the use of `unsafe`. Instead had we had `future::ready` available, we could've written the same example without using `unsafe`:
```rust
use core::task::{Context, Poll};
use core::future::{self, Future};
use core::pin::Pin;
pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
let mut fut = future::ready(42_u8);
let num = ready!(Pin::new(fut).poll(cx));
// ... use num
Poll::Ready(())
}
```
## Why future::ready?
Arguably `future::ready` and `async {}` can be considered equivalent. The main differences are that `future::ready` returns a future that implements `Unpin`, and the returned future is a concrete type. This is useful for traits that require a future as an associated type that can sometimes be a no-op ([example](https://docs.rs/http-service/0.4.0/http_service/trait.HttpService.html#associatedtype.ConnectionFuture)).
The final, minor argument is that `future::ready` and `future::pending` form a counterpart to the enum members of `Poll`: `Ready` and `Pending`. These functions form a conceptual bridge between `Poll` and `Future`, and can be used as a useful teaching device.
## References
- [`futures::future::ready`](https://docs.rs/futures/0.3.4/futures/future/fn.ready.html)
- [`futures::future::pending`](https://docs.rs/futures/0.3.4/futures/future/fn.pending.html)
- [`async_std::future::pending`](https://docs.rs/async-std/1.5.0/async_std/future/fn.pending.html)
- [`async_std::future::ready`](https://docs.rs/async-std/1.5.0/async_std/future/fn.ready.html)
This allows configuring the directory for build artifacts, instead of having it always be ./build. This means you can set it to a constant location, letting you reuse the same cache while working in several different directories.
The configuration lives in config.toml under build.build-dir. By default, it keeps the existing default of ./build, but it can be configured to any relative or absolute path. Additionally, it allows making outputs relative to the root of the git repository using $ROOT.
Changes:
````
more clippy fixes
Document that bench is unstable in the man page.
Update assertions in LTO calculations
Updated comments in resolve.rs to reflect actual data strcture used.
Try to remove secrets from http.debug.
Revert always computing filename Metadata.
clean -p: call `get_many` once.
Implement new `clean -p` using globs.
Rework how Cargo computes the rustc file outputs.
Add CrateType to replace LibKind.
````
This will reduce costs, as well as lays the groundwork for developers to be able
to locally pull the published docker images without needing AWS credentials.
Work around ICEs during cross-compilation for target, ast, & attr
This applies the fix for #72003 to work around #56935 to three more libraries. With these additional fixes, I'm able to use rustfmt_lib from wasm (https://github.com/rust-lang/rustfmt/issues/4132#issuecomment-616587989), which was my goal.
To get it working locally and to test, I copied the `.cargo/registry/src` and applied the fix and replaced the reference in my project:
``` toml
[replace]
"rustc-ap-rustc_span:656.0.0" = { path = "../rustc-ap-rustc_span" }
"rustc-ap-rustc_target:656.0.0" = { path = "../rustc-ap-rustc_target" }
"rustc-ap-rustc_ast:656.0.0" = { path = "../rustc-ap-rustc_ast" }
"rustc-ap-rustc_attr:656.0.0" = { path = "../rustc-ap-rustc_attr" }
```
allow wasm target for rustc-ap-rustc_span
This fixes#71998 by applying the work-a-round. The root cause is probably #56935, as @petrochenkov pointed out.
I reproduced the bug by:
```
cd ~/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-ap-rustc_span-657.0.0/
cargo build --target wasm32-unknown-unknown
```
Adding this line fixes it.
Reduce `TypedArena` creations in `check_match`.
`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.
This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)
r? @oli-obk
Improve bitcode generation for Apple platforms
Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton
This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE).
1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious.
2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section.
In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure.
Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.
Unify lints handling in rustdoc
This is a small cleanup. The goal is to unify a bit things to make the reading simpler.
r? @kinnison
cc @rust-lang/rustdoc
Rollup of 6 pull requests
Successful merges:
- #71989 (Use a single enum for the kind of a const context)
- #71993 (Remove old `util/liveness.rs` module)
- #71999 (Add myself to mailmap.)
- #72001 (Adjust cfg(version) to lang team decision)
- #72007 (Fix some tests failing in `--pass check` mode)
- #72008 (Add const-generics test)
Failed merges:
r? @ghost
Remove old `util/liveness.rs` module
The liveness dataflow analysis now lives in the `dataflow` module, so this one is no longer necessary. I've copied the relevant bits of the module docs for `util::liveness` to `MaybeLiveLocals`. The example in the docs is now a `mir-dataflow` test: a08c47310c/src/test/ui/mir-dataflow/liveness-ptr.rs (L6-L26)
The borrow-checker used the same notion of "defs" and "uses", so I've moved it into a submodule. I would have moved it to `util/def_use.rs`, since it seems generally useful, but there's already a slightly [different version](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/util/def_use.rs) of the same abstraction needed for copy propagation.
Use a single enum for the kind of a const context
This adds a `ConstContext` enum to the `rustc_hir` crate and method that can be called via `tcx.hir()` to get the `ConstContext` for a given body owner. This arose from discussion in #71824.
r? @oli-obk
Extend example for the `unneeded_field_pattern` lint
Current example is incorrect (or pseudo-code) because a struct name is omitted. I have used the code from the tests instead. Perhaps this example can be made less verbose, but I think it is more convenient to see a "real" code as an example.
---
changelog: extend example for the `unneeded_field_pattern` lint
