Allow `use super::*;` glob imports
changelog: Allow super::* glob imports
fixes#5554fixes#5569
A first pass at #5554 - this allows all `use super::*` to pass, which may or may not be desirable. The original issue was around allowing test modules to import their entire parent modules - I'm happy to modify this to do that instead, may just need some guidance on how to implement that (I played around a bit with #[cfg(test)] but from what I can gather, clippy itself isn't in test mode when running, even if the code in question is being checked for the test target).
Simplify the `tcx.alloc_map` API
This PR changes all functions that require manually locking the `alloc_map` to functions on `TyCtxt` that lock the map internally. In the same step we make the `TyCtxt::alloc_map` field private.
r? @RalfJung
rustllvm: Use .init_array rather than .ctors
LLVM TargetMachines default to using the (now-legacy) .ctors
representation of init functions. Mixing .ctors and .init_array
representations can cause issues when linking with lld.
This happens in practice for:
* Our profiling runtime which is currently implicitly built with
.init_array since it is built by clang, which sets this field.
* External C/C++ code that may be linked into the same process.
Fixes: #71233
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.
