Slight simplification of chars().count()
Slight simplification: No need to call len(), we can just count the number of non continuation bytes.
I can't see any reason not to do this, can you?
Support FRU pattern with `[feature(capture_disjoint_fields)]`
In case of a functional record update syntax for creating a structure, `ExprUseVisitor` to only detect the precise use of some of the field in the `..x` part of the syntax. However, when we start building MIR, we
1. First, build the place for `x`
2. and then, add precise field projections so that only some parts of `x` end up getting read.
When `capture_disjoint_fields` is enabled, and FRU is used within a closure `x` won't be completely captured, and therefore the first step will fail. This PR updates `mir_build` to create a place builder in the first step and then create place from the builder only after applying the field projection.
Closes https://github.com/rust-lang/project-rfc-2229/issues/32
r? ``````@nikomatsakis``````
Stabilize `unsigned_abs`
Resolves#74913.
This PR stabilizes the `i*::unsigned_abs()` method, which returns the absolute value of an integer _as its unsigned equivalent_. This has the advantage that it does not overflow on `i*::MIN`.
I have gone ahead and used this in a couple locations throughout the repository.
Stabilize raw ref macros
This stabilizes `raw_ref_macros` (https://github.com/rust-lang/rust/issues/73394), which is possible now that https://github.com/rust-lang/rust/issues/74355 is fixed.
However, as I already said in https://github.com/rust-lang/rust/issues/73394#issuecomment-751342185, I am not particularly happy with the current names of the macros. So I propose we also change them, which means I am proposing to stabilize the following in `core::ptr`:
```rust
pub macro const_addr_of($e:expr) {
&raw const $e
}
pub macro mut_addr_of($e:expr) {
&raw mut $e
}
```
The macro name change means we need another round of FCP. Cc `````@rust-lang/libs`````
Fixes#73394
Consider Scalar to be a bool only if its unsigned
This seems right, given that conceptually bools are unsigned, but the
implications of this change may have more action at distance that I'm
not sure how to exhaustively consider.
For instance there are a number of cases where code attaches range
metadata if `scalar.is_bool()` holds. Supposedly it would no longer be
attached to the `repr(i8)` enums? Though I'm not sure why booleans are
being special-cased here in the first place...
Fixes#80556
cc `@eddyb`
Add `core::stream::Stream`
[[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)]
This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet, but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling.
## Documentatation
The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html), [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html), and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as "infinite streams" and "laziness" in more depth.
## Feature gate
The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = "future_trait"]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate, with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization, as was the case with `std::future`.
__edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC.
## Conclusion
This PR introduces `core::stream::{Stream, Next}` and re-exports it from `std` as `std::stream::{Stream, Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen!
---
r? `````@KodrAus`````
cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````
Update Python and Clang on x86 dist images
LLVM 12 no longer builds with Python 2, so install Python 3 in
preparation for the upgrade (#81451).
However, Clang 10 does not build with Python 3, so we need update
to Clang 11 as well, which supports both.
Unfortunately, doing so results in errors while linking the
libLLVM.so into other binaries:
> __morestack: invalid needed version 2
This is fixed by using LLD instead. Possibly this is due to a binutils
linker bug, but updating to the latest binutils version does not fix
it.
r? `@Mark-Simulacrum`
cc `@cuviper`
As described in https://github.com/rust-lang/rust/issues/68574, the currently exposed API for symlinks is, in fact, a thin wrapper around the corresponding syscall, and not suitable for public usage.
The reason is that the 2nd param in the call is expected to be a handle of a "preopened directory" (a WASI concept for exposing dirs), and the only way to retrieve such handle right now is by tinkering with a private `__wasilibc_find_relpath` API, which is an implementation detail and definitely not something we want users to call directly.
Making matters worse, the semantics of this param aren't obvious from its name (`fd`), and easy to misinterpret, resulting in people trying to pass a handle of the target file itself (as in https://github.com/vitiral/path_abs/pull/50), which doesn't work as expected.
I did a codesearch among open-source repos, and the usage above is so far the only usage of this API at all, but we should fix it before more people start using it incorrectly.
While this is technically a breaking API change, I believe it's a justified one, as 1) it's OS-specific and 2) there was strictly no way to correctly use the previous form of the API, and if someone does use it, they're likely doing it wrong like in the example above.
The new API does not lead to the same confusion, as it mirrors `std::os::unix::fs::symlink` and `std::os::windows::fs::symlink_{file,dir}` variants by accepting source/target paths.
Fixes#68574.
rustdoc tweaking
* Reuse memory
* simplify `next_def_id`, avoid multiple hashing and unnecessary lookups
* remove `all_fake_def_ids`, use the global map instead (probably not a good step toward parallelization, though...)
* convert `add_deref_target` to iterative implementation
* use `ArrayVec` where we know the max number of elements
* minor touchups here and there
* avoid building temporary vectors that get appended to other vectors
At most places I may or may not be doing the compiler's job is this PR.
* Reuse memory
* simplify `next_def_id`, avoid multiple hashing and unnecessary lookups
* remove `all_fake_def_ids`, use the global map instead (probably not a good step toward parallelization, though...)
* convert `add_deref_target` to iterative implementation
* use `ArrayVec` where we know the max number of elements
* minor touchups here and there
* avoid building temporary vectors that get appended to other vectors
At most places I may or may not be doing the compiler's job is this PR.
This requires updating the used Linux kernel to avoid an assembler
error, the used busybox version to avoid a linker error, the used
rootfs to match the host version and the qemu flags to work with
the newer version.
This seems right, given that conceptually bools are unsigned, but the
implications of this change may have more action at distance that I'm
not sure how to exhaustively consider.
For instance there are a number of cases where code attaches range
metadata if `scalar.is_bool()` holds. Supposedly it would no longer be
attached to the `repr(i8)` enums? Though I'm not sure why booleans are
being special-cased here in the first place...
Fixes#80556
Previously, only the end of pass RSS was indicated. This could easily
lead one to believe that the change in RSS from one pass to the next was
attributable to the second pass, when in fact it occurred between the
end of the first pass and the start of the second.
Also, improve alignment of columns.
When `capture_disjoint_fields` is not enabled, checking if the root variable
binding is mutable would suffice.
However with the feature enabled, the captured place might be mutable
because it dereferences a mutable reference.
This PR computes the mutability of each capture after capture analysis
in rustc_typeck. We store this in `ty::CapturedPlace` and then use
`ty::CapturedPlace::mutability` in mir_build and borrow_check.
- No Derefs in move closure, this will result in value behind a reference getting moved.
- No projections are applied to raw pointers, since these require unsafe blocks. We capture
them completely.
Motivations for these are recorded here: https://hackmd.io/71qq-IOpTNqzMkPpAI1dVg?view
This makes it clear that it's an implementation detail of `display_fn`
and shouldn't be used elsewhere, and it enforces in the compiler that no
one else can use it.
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 becomes
relevant only now though, as this was apparently the case since
kernel 2.6.4.
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.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
On Windows, libstd uses GetProcAddress to locate some DLL imports, so
that libstd can run on older versions of Windows. If a given DLL import
is not present, then libstd uses other behavior (such as fallback
implementations).
This commit uses a feature of the Windows CRT to do these DLL imports
during module initialization, before main() (or DllMain()) is called.
This is the ideal time to resolve imports, because the module is
effectively single-threaded at that point; no other threads can
touch the data or code of the module that is being initialized.
This avoids several problems. First, it makes the cost of performing
the DLL import lookups deterministic. Right now, the DLL imports are
done on demand, which means that application threads _might_ have to
do the DLL import during some time-sensitive operation. This is a
small source of unpredictability. Since threads can race, it's even
possible to have more than one thread running the same redundant
DLL lookup.
This commit also removes using the heap to allocate strings, during
the DLL lookups.
This updates the dist-various-1 and dist-various-2 images to Ubuntu
20.04. This requires some adjustments:
* `DEBIAN_FRONTEND=noninteractive` required for apt install.
* `team-gcc-argm-embedded` PPA does not support focal. However,
we can simply use the distro-provided `gcc-arm-none-eabi`. Per
the comment, the PPA was only used to get a newer version.
* rumprun has to be updated to avoid a linker error.
* We need to build rumrun with `NOGCCERROR`, which disables use
of `-Werror` and allows building with a newer compiler.
* We need to install `libtinfo5`, which appears to be a dependency
of the clang used during the fuchsia build.
* We need to switch to `g++-8` rather than `g++-7`, as at least
`g++-7-arm-linux-gnueabi` is not available on focal.
* We need to upgrade to GCC 6.5 for the Solaris build, as GCC 6.4
does not support the newer libisl version.
Before, it could print this error if no toolchain was configured:
```
error: no default toolchain configured
error: backtrace:
error: stack backtrace:
0: error_chain::backtrace:👿:InternalBacktrace::new
1: rustup::config::Cfg::toolchain_for_dir
2: rustup_init::run_rustup_inner
3: rustup_init::main
4: std::rt::lang_start::{{closure}}
5: main
6: __libc_start_main
7: _start
```
Avoid memory allocation when removing dead blocks
Use `reachable_as_bitset` to reuse a bitset from the traversal rather
than allocating it seprately. Additionally check if there are any
unreachable blocks before proceeding.
Pre-canoncalize ExternLocation::ExactPaths
This stores pre-canacolized paths inside `ExternLocation::ExactPaths` so that we don't need to canoncalize them every time we want to compare them to source lib paths.
This is related to #81414.
This commit makes cfg(version) treat the nightlies
for version 1.n.0 as 1.n.0, even though that nightly
version might not have all stabilizations and features
of the released 1.n.0. This is done for greater
convenience for people who want to test a newly
stabilized feature on nightly.
For users who wish to pin nightlies, this commit adds
a -Z assume-incomplete-release option that they can
enable if there are any issues due to this change.
