Commit Graph

5221 Commits

Author SHA1 Message Date
Michael Hall
51cf318dbc remove unnecessary empty check 2021-08-17 12:26:24 +10:00
Mara Bos
fa4edcc851
Rollup merge of #88030 - fee1-dead:fixme, r=oli-obk
Assign FIXMEs to me and remove obsolete ones

Also fixed capitalization of documentation

We also don't need to transform predicates to be non-const since we basically ignore const predicates in non-const contexts.

r? `````@oli-obk`````
2021-08-16 23:37:30 +02:00
The8472
ff12ab2d99 correct overflows in the backslide case, add test 2021-08-16 22:15:52 +02:00
Cameron Steffen
f4ef07c2a9 Get piece unchecked in write 2021-08-16 16:28:16 +00:00
Cameron Steffen
975bc18481 Make Arguments constructors unsafe 2021-08-16 16:28:16 +00:00
bors
0035d9dcec Auto merge of #87050 - jyn514:no-doc-primitive, r=manishearth
Add future-incompat lint for `doc(primitive)`

## What is `doc(primitive)`?

`doc(primitive)` is an attribute recognized by rustdoc which adds documentation for the built-in primitive types, such as `usize` and `()`. It has been stable since Rust 1.0.

## Why change anything?

`doc(primitive)` is useless for anyone outside the standard library. Since rustdoc provides no way to combine the documentation on two different primitive items, you can only replace the docs, and since the standard library already provides extensive documentation there is no reason to do so.

While fixing rustdoc's handling of primitive items (https://github.com/rust-lang/rust/pull/87073) I discovered that even rustdoc's existing handling of primitive items was broken if you had more than two crates using it (it would pick randomly between them). That meant both:
- Keeping rustdoc's existing treatment was nigh-impossible, because it was random.
- doc(primitive) was even more useless than it would otherwise be.

The only use-case for this outside the standard library is for no-std libraries which want to link to primitives (https://github.com/rust-lang/rust/issues/73423) which is being fixed in https://github.com/rust-lang/rust/pull/87073.

https://github.com/rust-lang/rust/pull/87073 makes various breaking changes to `doc(primitive)` (breaking in the sense that they change the semantics, not in that they cause code to fail to compile). It's not possible to avoid these and still fix rustdoc's issues.

## What can we do about it?

As shown by the crater run (https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706), no one is actually using doc(primitive), there wasn't a single true regression in the whole run. We can either:
1. Feature gate it completely, breaking anyone who crater missed. They can easily fix the breakage just by removing the attribute.
2. add it to the `INVALID_DOC_ATTRIBUTES` future-incompat lint, and at the same time make it a no-op unless you add a feature gate. That would mean rustdoc has to look at the features of dependent crates, because it needs to know where primitives are defined in order to link to them.
3. add it to `INVALID_DOC_ATTRIBUTES`, but still use it to determine where primitives come from
4. do nothing; the behavior will silently change in https://github.com/rust-lang/rust/pull/87073.

My preference is for 2, but I would also be happy with 1 or 3. I don't think we should silently change the behavior.

This PR currently implements 3.
2021-08-16 15:36:44 +00:00
bors
92f3753b07 Auto merge of #84039 - jyn514:uplift-atomic-ordering, r=wesleywiser
Uplift the invalid_atomic_ordering lint from clippy to rustc

This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.

r? `@lcnr` since you reviewed the last one, but feel free to reassign.

---

This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.

As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.

As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.

In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?

---

Some notes on the code for reviewers / others below

## Changes from clippy

The code is changed from [the implementation in clippy](68cf94f6a6/clippy_lints/src/atomic_ordering.rs) in the following ways:

1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
    - It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
    - There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
    - I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
    - These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
    - grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
    - function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
    - avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).

## Potential issues

(This is just about the code in this PR, not conceptual issues with the lint or anything)

1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
    - It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.

2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
    - I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.

3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.

4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).
2021-08-16 06:36:13 +00:00
Xuanwo
e32f4c06d3
Remove extra empty lines
Signed-off-by: Xuanwo <github@xuanwo.io>
2021-08-16 13:45:34 +08:00
Joshua Nelson
03df65497e feature gate doc(primitive) 2021-08-16 05:41:16 +00:00
Xuanwo
b4b495e48e
Optimize unnecessary check in VecDeque::retain
Signed-off-by: Xuanwo <github@xuanwo.io>
2021-08-16 13:37:51 +08:00
Thom Chiovoloni
402a9c9f5e Uplift the invalid_atomic_ordering lint from clippy to rustc
- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead

  I ran into tons of trouble with this because apparently the change to
  store HIR attrs in a side table also gave the DefIds of the
  constructor instead of the variant itself. So I had to change
  `matches_ordering` to also check the grandparent of the defid as well.

- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
  Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches

  This prevents an ICE when there aren't enough arguments.

- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`

  The functions take values, so this couldn't ever be anything else.

- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow
2021-08-16 03:55:27 +00:00
bors
23461b210f Auto merge of #87696 - ssomers:btree_lazy_iterator_cleanup, r=Mark-Simulacrum
BTree: merge the complication introduced by #81486 and #86031

Also:
- Deallocate the last few tree nodes as soon as an `into_iter` iterator steps beyond the end, instead of waiting around for the drop of the iterator (just to share more code).
- Symmetric code for backward iteration.
- Mark unsafe the methods on dying handles, modelling dying handles after raw pointers: it's the caller's responsibility to use them safely.

r? `@Mark-Simulacrum`
2021-08-16 03:45:26 +00:00
the8472
7256a6a86d
Apply suggestions from code review
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2021-08-16 00:01:41 +02:00
ibraheemdev
58f988fa40 move object safety test to library/core 2021-08-15 13:00:25 -04:00
Amanieu d'Antras
6fd4f3463f Allow the use of the deprecated llvm_asm! in black_box 2021-08-15 13:14:32 +01:00
Amanieu d'Antras
4dd933cdc2 Deprecate llvm_asm! 2021-08-15 13:14:32 +01:00
bors
40db258731 Auto merge of #87974 - steffahn:slice_split_size_hints, r=dtolnay
Test and fix `size_hint` for slice’s [r]split* iterators

Adds extensive test (of `size_hint`) for all the _[r]split*_ iterators.
Fixes `size_hint` upper bound for _split_inclusive*_ iterators which was one higher than necessary for non-empty slices.
Fixes `size_hint` lower bound for _[r]splitn*_ iterators when _n == 0_, which was one too high.

**Lower bound being one too high was a logic error, violating the correctness condition of `size_hint`.**

_Edit:_ I’ve opened an issue for that bug, so this PR fixes #87978
2021-08-15 04:48:42 +00:00
ibraheemdev
481b282e8a make BuildHasher object safe 2021-08-14 13:25:02 -04:00
Deadbeef
f25d2bd53b
Assign FIXMEs to me and remove obsolete ones
Also fixed capitalization of documentation
2021-08-14 16:48:01 +00:00
bors
a59e885314 Auto merge of #87913 - a1phyr:vec_spec_clone_from, r=dtolnay
Specialize `Vec::clone_from` for `Copy` types

This should improve performance and reduce code size.

This also improves `clone_from` for `String`, `OsString` and `PathBuf`.
2021-08-14 14:52:33 +00:00
Dan Gohman
35de5c9b35 Change WASI's RawFd from u32 to c_int (i32).
WASI previously used `u32` as its `RawFd` type, since its "file descriptors"
are unsigned table indices, and there's no fundamental reason why WASI can't
have more than 2^31 handles.

However, this creates myriad little incompability problems with code
that also supports Unix platforms, where `RawFd` is `c_int`. While WASI
isn't a Unix, it often shares code with Unix, and this difference made
such shared code inconvenient. #87329 is the most recent example of such
code.

So, switch WASI to use `c_int`, which is `i32`. This will mean that code
intending to support WASI should ideally avoid assuming that negative file
descriptors are invalid, even though POSIX itself says that file descriptors
are never negative.

This is a breaking change, but `RawFd` is considerd an experimental
feature in [the documentation].

[the documentation]: https://doc.rust-lang.org/stable/std/os/wasi/io/type.RawFd.html
2021-08-13 09:10:22 -07:00
Frank Steffahn
3f0d04e97b Improve wording, correct -> tight. 2021-08-13 15:27:30 +02:00
Stefan Lankes
bbb6cb8969 switch to the latest version of hermit-abi 2021-08-13 13:05:13 +02:00
Frank Steffahn
4304686049 Consistent use of impl Trait arguments in the test's helper function. 2021-08-13 12:02:35 +02:00
Deadbeef
8c2a1e8e43
allow incomplete features for now 2021-08-13 09:28:52 +00:00
Deadbeef
7ea0280aa9
Moved ui test 2021-08-13 09:28:51 +00:00
Martin Kröning
fffa88eb27 Don't put hermit mutexes in a box.
Hermit mutexes are movable.
2021-08-13 07:43:05 +02:00
Martin Kröning
f45ebe459f Don't put hermit condvars in a box.
Hermit condvars are movable.
2021-08-13 07:42:49 +02:00
Martin Kröning
fe56e8961f Don't put hermit rwlocks in a box.
Hermit rwlocks are movable.
2021-08-13 07:42:27 +02:00
The8472
a98a30976b add benchmarks for 1, 2, 4, 8, 16 threads 2021-08-13 00:19:03 +02:00
The8472
3914a7b0da where available use 64- or 128bit atomics instead of a Mutex to monotonize time 2021-08-13 00:18:46 +02:00
Frank Steffahn
0bb11f43f6 Rewrite test from previous commit but without using macros. 2021-08-12 23:11:19 +02:00
bors
0fa3190394 Auto merge of #87916 - nbdd0121:black_box, r=nagisa
Implement `black_box` using intrinsic

Introduce `black_box` intrinsic, as suggested in https://github.com/rust-lang/rust/pull/87590#discussion_r680468700.

This is still codegenned as empty inline assembly for LLVM. For MIR interpretation and cranelift it's treated as identity.

cc `@Amanieu` as this is related to inline assembly
cc `@bjorn3` for rustc_codegen_cranelift changes
cc `@RalfJung` as this affects MIRI

r? `@nagisa` I suppose
2021-08-12 21:04:07 +00:00
Frank Steffahn
31e49f0272 Test and fix size_hint for slice's [r]split* iterators
Adds extensive test for all the [r]split* iterators.
Fixes size_hint upper bound for split_inclusive* iterators which was one higher than necessary for non-empty slices.
Fixes size_hint lower bound for [r]splitn* iterators when n==0, which was one too high.
2021-08-12 17:26:03 +02:00
Gary Guo
1fb1643129 Implement black_box using intrinsic
The new implementation allows some `memcpy`s to be optimized away,
so the uninit value in ui/sanitize/memory.rs is constructed directly
onto the return place. Therefore the sanitizer now says that the
value is allocated by `main` rather than `random`.
2021-08-12 16:16:57 +01:00
bors
4498e300e4 Auto merge of #87963 - GuillaumeGomez:rollup-e54sbez, r=GuillaumeGomez
Rollup of 4 pull requests

Successful merges:

 - #87819 (Use a more accurate span on assoc types WF checks)
 - #87863 (Fix Windows Command::env("PATH"))
 - #87885 (Link to edition guide instead of issues for 2021 lints.)
 - #87941 (Fix/improve rustdoc-js tool)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-08-12 13:24:29 +00:00
Michael Watzko
f136eea97c Implement Neg only for signed Saturating types 2021-08-12 13:43:49 +02:00
Guillaume Gomez
cc54fdadd2
Rollup merge of #87863 - ChrisDenton:command-env-path-fix, r=dtolnay
Fix Windows Command::env("PATH")

Fixes #87859
2021-08-12 13:25:06 +02:00
bors
6bed1f0bc3 Auto merge of #87666 - ivmarkov:master, r=Amanieu
STD support for the ESP-IDF framework

Dear all,

This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework, which is the open source SDK provided by Espressif for their MCU family (esp32, esp32s2, esp32c3 and all other forthcoming ones).

Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate, which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support.

# Implementation approach

The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread`, BSD sockets, file descriptors, and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes, which is to be expected of course on bare metal.

Therefore, the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules, in the form of conditional-compilation branches based either on `target_os = "espidf"` or in a couple of cases - based on `target_env = "newlib"` (the latter was already there actually and is not part of this patch).

The PR also contains two new targets:
- `riscv32imc-esp-espidf`
- `riscv32imac-esp-espidf`

... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf`, but enriched with proper `linker`, `linker_flavor`, `families`, `os`, `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used.

Since support for atomics is a precondition for libStd, the `riscv32imc-esp-espidf` target additionally is configured in such a way, so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions, which are already implemented in the ESP-IDF framework. If this modification is not acceptable, we can also live with only the `riscv32imac-esp-espidf` target as well.  While the RiscV chips of Espressif lack native atomics support, the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind.

# Target maintainers

In case this PR eventually gets merged, you can list myself as a Target Maintainer.

More importantly, Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that, I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well.

**EDIT:** I was hinted (thanks, `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below.

# Tier 3 Target Policy - answers

> A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

Hopefully, the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is, aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`).

> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

`@ivmarkov`
`@MabezDev`

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base:
* The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`.
* `_elf` was removed, as the non-bare metal targets seem not to have it
* `-newlib` was deliberately NOT added at the end, as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say, newlib vs musl) is way too small
* Finally, we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company, as they all use the riscv32imc instruction set. By necessity however (disambiguation), it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR, even though they would use 1:1 the same LibStd implementation provided here, as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.)

There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14).

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

Agreed.

> The target must not introduce license incompatibilities.

To the best of our knowledge, it doesn't.

> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

MIT + Apache 2.0

> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.

Requirements are not changed for any other target.

> If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.

The targets are for bare-metal environment which is not hosting build tools or a compiler.

> Targets should not require proprietary (non-FOSS) components to link a functional binary or library.

The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL.

> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Agreed.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

The targets implement libStd almost in its entirety, except for the missing support for process, as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return "not implemented" errors.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file, but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs), there is no need for extensive documentation.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Agreed.

> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Agreed.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

To the best of our knowledge, we believe we are not breaking any other target (be it tier 1, 2 or 3).

> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

To the best of our knowledge, we have not introduced any unconditional use of a feature that affects any other target.

> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.

Agreed.
2021-08-12 10:33:14 +00:00
Michael Watzko
7861121ae4 Add naive remainder impl to Saturating 2021-08-12 12:28:30 +02:00
Michael Watzko
3f7d2ce28f Add naive shift implementation to Saturating 2021-08-12 12:26:10 +02:00
Michael Watzko
e240853dfc Replace doc test with doc macro call 2021-08-12 12:08:30 +02:00
Michael Watzko
57dacfe4d1 Like in Wrapping use shift in doctest 2021-08-12 11:25:03 +02:00
Benoît du Garreau
94d6b22fc3 Add missing cfg attribute 2021-08-12 10:48:04 +02:00
Michael Watzko
6cf4dd975b Remove mentioning of modular arithmetic 2021-08-12 10:05:38 +02:00
Michael Watzko
631766c055 Make all the impls for Staturating unstable saturating_int_impl 2021-08-12 09:06:43 +02:00
Yuki Okushi
688094b868
Rollup merge of #85835 - Seppel3210:master, r=yaahc
Implement Extend<(A, B)> for (Extend<A>, Extend<B>)

I oriented myself at the implementation of `Iterator::unzip` and also rewrote the impl in terms of `(A, B)::extend` after that.

Since (A, B) now also implements Extend we could also mention in the documentation of unzip that it can do "nested unzipping" (you could unzip `Iterator<Item=(A, (B, C))>` into `(Vec<A>, (Vec<B>, Vec<C>))` for example) but I'm not sure of that so I'm asking here 🙂

(P.S. I saw a couple of people asking if there is an unzip3 but there isn't. So this could be a way to get equivalent functionality)
2021-08-12 15:32:53 +09:00
bors
25d3e14da7 Auto merge of #87843 - kornelski:try_reserve, r=m-ou-se
TryReserveErrorKind tests and inline

A small follow-up to #87408
2021-08-12 01:16:22 +00:00
bors
362e0f55eb Auto merge of #87892 - rust-lang:spec-fill-size-one-bye, r=the8472
Remove size_of == 1 case from `fill` specialization.

Fixes https://github.com/rust-lang/rust/issues/87891

See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/potential.20UB.20in.20slice.3A.3Afill/near/248875743).
2021-08-11 11:40:20 +00:00
Yuki Okushi
9d21b5a39d
Rollup merge of #87876 - lcnr:windows_no_panic, r=m-ou-se
add `windows` count test

cc #87767
2021-08-11 04:18:43 +09:00
Yuki Okushi
6412bf98ea
Rollup merge of #87848 - godmar:@godmar/thread-join-documentation-fix, r=joshtriplett
removed references to parent/child from std::thread documentation

- also clarifies how thread.join and detaching of threads works
- the previous prose implied that there is a relationship between a
spawning thread and the thread being spawned, and that "child" threads
couldn't outlive their "parents" unless detached, which is incorrect.
2021-08-11 04:18:38 +09:00
Yuki Okushi
bdc92f10e7
Rollup merge of #87636 - Kixiron:unzip-option, r=scottmcm
Added the `Option::unzip()` method

* Adds the `Option::unzip()` method to turn an `Option<(T, U)>` into `(Option<T>, Option<U>)` under the `unzip_option` feature
* Adds tests for both `Option::unzip()` and `Option::zip()`, I noticed that `.zip()` didn't have any
* Adds `#[inline]` to a few of `Option`'s methods that were missing it
2021-08-11 04:18:34 +09:00
Yuki Okushi
3b41447a02
Rollup merge of #86840 - usbalbin:const_from, r=oli-obk
Constify implementations of `(Try)From` for int types

I believe this to be one of the (many?) things blocking const (Range) iterators.

~~If this is to be merged maybe that should wait until `#![feature(const_trait_impl)]` no longer needs `#![allow(incomplete_features)]`?~~ - Done
2021-08-11 04:18:33 +09:00
Michael Watzko
d4c9f76fd2 Fix missed tests 2021-08-10 20:34:08 +02:00
Michael Watzko
cdc90f9281 Rustfmt 2021-08-10 19:53:42 +02:00
Michael Watzko
8841155ce5 Remove unused macros 2021-08-10 19:51:49 +02:00
Michael Watzko
709a6c913e Add Saturating type (based on Wrapping type) 2021-08-10 19:27:01 +02:00
Benoît du Garreau
361398009b Specialize Vec::clone_from for Copy types
This should improve performance and reduce code size.

This also improves `clone_from` for `String`, `OsString` and `PathBuf`.
2021-08-10 11:53:40 +02:00
ivmarkov
459eaa6bae STD support for the ESP-IDF framework 2021-08-10 12:09:00 +03:00
Kevin Reid
07988bb8a1 Reword description of automatic impls of Unsize.
The existing documentation felt a little unhelpfully concise, so this
change tries to improve it by using longer sentences, each of which
specifies which kinds of types it applies to as early as possible. In
particular, the third item starts with “Structs ...” instead of
saying “Foo is a struct” later.

Also, the previous list items “Only the last field has a type
involving `T`” and “`T` is not part of the type of any other
fields” are, as far as I see, redundant with each other, so I removed
the latter.
2021-08-09 18:55:39 -07:00
Mara Bos
38383017d6 Remove size_of == 1 case from fill specialization. 2021-08-09 19:25:28 +02:00
Chase Wilson
ab2c5902ca
Added tracking issue to unstable attribute 2021-08-09 10:24:03 -05:00
Chase Wilson
9d8081e8b6
Enabled unzip_option feature for core tests & unzip docs 2021-08-09 10:24:02 -05:00
Chase Wilson
eea3520a8f
Added some basic tests for Option::unzip() and Option::zip() (I noticed that zip had no tests) 2021-08-09 10:24:00 -05:00
Chase Wilson
bc4ce79764
Added the Option::unzip() method 2021-08-09 10:23:46 -05:00
lcnr
24aa45c95e add windows count test 2021-08-09 11:08:39 +02:00
bors
eaf6f46359 Auto merge of #87820 - elichai:patch-2, r=kennytm
Replace read_to_string with read_line in Stdin example

The current example results in infinitely reading from stdin, which can confuse newcomers trying to read from stdin.
(`@razmag` encountered this while learning the language from the docs)
2021-08-09 08:19:19 +00:00
Richard Schneeman
2d639ce67c ## Context
While going through the "The Rust Programming Language" book (Klabnik & Nichols), the TCP server example directs us to use TcpListener::incoming. I was curious how I could pass this value to a function (before reading ahead in the book), so I looked up the docs to determine the signature. 

When I opened the docs, I found https://doc.rust-lang.org/std/net/struct.TcpListener.html#method.incoming, which didn't mention TcpStream anywhere in the example.

Eventually, I clicked on https://doc.rust-lang.org/std/net/struct.TcpListener.html#method.accept in the docs (after clicking a few other locations first), and was able to surmise that the value contained TcpStream.

## Opportunity

While this type is mentioned several times in this doc, I feel that someone should be able to fully use the results of the TcpListner::incoming iterator based solely on the docs of just this method.

## Implementation

I took the code from the top-level TcpListener https://doc.rust-lang.org/std/net/struct.TcpListener.html#method.incoming and blended it with the existing docs for TcpListener::incoming https://doc.rust-lang.org/std/net/struct.TcpListener.html#method.incoming.

It does make the example a little longer, and it also introduces a little duplication. It also gives the reader the type signatures they need to move on to the next step.

## Additional considerations

I noticed that in this doc, `handle_connection` and `handle_client` are both used to accept a TcpStream in the docs on this page. I want to standardize on one function name convention, so readers don't accidentally think two different concepts are being referenced. I didn't want to cram do too much in one PR, I can update this PR to make that change, or I could send another PR (if you would like).

First attempted contribution to Rust (and I'm also still very new, hence reading through the rust book for the first time)! Would you please let me know what you think?
2021-08-08 21:23:18 -05:00
Chris Denton
e26dda5642
Implement modern Windows arg parsing
As derived from extensive testing of `argv` in a C/C++ application.

Co-Authored-By: Jane Lusby <jlusby42@gmail.com>
2021-08-08 22:11:30 +01:00
Chris Denton
565a51973a
Update Windows arg parsing tests
This updates the tests to be consistent with argv in modern C/C++ applications.
2021-08-08 22:11:29 +01:00
bors
ad981d58e1 Auto merge of #86879 - YohDeadfall:stabilize-vec-shrink-to, r=dtolnay
Stabilize Vec<T>::shrink_to

This PR stabilizes `shrink_to` feature and closes the corresponding issue. The second point was addressed already, and no `panic!` should occur.

Closes #56431.
2021-08-08 19:37:02 +00:00
David Tolnay
8ec5060cdd
Bump shrink_to stabilization to Rust 1.56 2021-08-08 11:36:53 -07:00
Chris Denton
419902e413
Fix Windows Command::env("PATH") 2021-08-08 16:03:39 +01:00
bors
4e886d6876 Auto merge of #87827 - eddyb:wrapperless-mem-replace, r=m-ou-se
Avoid using the `copy_nonoverlapping` wrapper through `mem::replace`.

This is a much simpler way to achieve the pre-#86003 behavior of `mem::replace` not needing dynamically-sized `memcpy`s (at least before inlining), than re-doing #81238 (which needs #86699 or something similar).

I didn't notice it until recently, but `ptr::write` already explicitly avoided using the wrapper, while `ptr::read` just called the wrapper (and was the reason for us observing any behavior change from #86003 in Rust-GPU).

<hr/>

The codegen test I've added fails without the change to `core::ptr::read` like this (ignore the `v0` mangling, I was using a worktree with it turned on by default, for this):
```llvm
       13: ; core::intrinsics::copy_nonoverlapping::<u8>
       14: ; Function Attrs: inlinehint nonlazybind uwtable
       15: define internal void `@_RINvNtCscK5tvALCJol_4core10intrinsics19copy_nonoverlappinghECsaS4X3EinRE8_25mem_replace_direct_memcpy(i8*` %src, i8* %dst, i64 %count) unnamed_addr #0 {
       16: start:
       17:  %0 = mul i64 %count, 1
       18:  call void `@llvm.memcpy.p0i8.p0i8.i64(i8*` align 1 %dst, i8* align 1 %src, i64 %0, i1 false)
not:17      !~~~~~~~~~~~~~~~~~~~~~                                                                     error: no match expected
       19:  ret void
       20: }
```
With the `core::ptr::read` change, `core::intrinsics::copy_nonoverlapping` doesn't get instantiated and the test passes.

<hr/>

r? `@m-ou-se` cc `@nagisa` (codegen test) `@oli-obk` / `@RalfJung` (miri diagnostic changes)
2021-08-08 13:11:09 +00:00
Eduard-Mihai Burtescu
a1d014bdbc Avoid using the copy_nonoverlapping wrapper through mem::replace. 2021-08-08 13:59:36 +03:00
bors
e8c25f2663 Auto merge of #87836 - tsoutsman:master, r=petrochenkov
Change proc_macro::Diagnostics docs

With Rust 1.54 attributes can invoke function-like macros. This allows functions generated by macros to have non-generic documentation. This pull request changes the documentation of `proc_macro::Diagnostics` to be more specific and include a link to the level.
## Example
Before:
```markdown
Adds a new child diagnostic message to `self` with the level
identified by this method’s name with the given `message`.
```
After:
```markdown
Adds a new child diagnostic message to self with the [`Level::Error`]
level, and the given `message`.
```
2021-08-08 10:23:17 +00:00
Klim Tsoutsman
26bf0ef0b5
Merge branch 'rust-lang:master' into master 2021-08-08 13:17:23 +10:00
bors
835dce569d Auto merge of #86744 - ijackson:sink-default, r=dtolnay
impl Default, Copy, Clone for std::io::Sink and Empty

The omission of `Sink: Default` is causing me a slight inconvenience in a test harness.  There seems little reason for this and `Empty` not to be `Clone` and `Copy` too.

I have made all three of these insta-stable, because:

AIUI `Copy` can only be derived, and I was not able to find any examples of how to unstably derive it.  I think it is probably not possible.

I hunted through the git history for precedent and found

> 79b8ad84c8
> Implement `Copy` for `IoSlice`
> https://github.com/rust-lang/rust/pull/69403

which was also insta-stable.
2021-08-08 01:52:32 +00:00
Albin Hedman
c8bf5ed628
Add test for int to float 2021-08-07 19:03:34 +02:00
Albin Hedman
09928a9a20
Add tests 2021-08-07 19:03:33 +02:00
Albin Hedman
eefd790d3b
impl const From<num> for num 2021-08-07 19:03:08 +02:00
Yuki Okushi
c159806cf0
Rollup merge of #87842 - steffahn:hidden_broken_intra_doc, r=dtolnay
Fix intra doc link in hidden doc of Iterator::__iterator_get_unchecked

Recently, I edited the import list of the `core::iter::traits::iterator` module (in #85874). This results in a broken intra doc link in a hidden documentation with the effect that `RUSTDOCFLAGS='--document-private-items --document-hidden-items' x doc library/std` fails. (This can be worked around by adding `-Arustdoc::broken-intra-doc-links`; still, it’s a broken link so let’s fix it.)

``@rustbot`` label C-cleanup, T-libs
2021-08-08 01:13:45 +09:00
Yuki Okushi
349290047f
Rollup merge of #87838 - jetomit:add-readdir-note, r=dtolnay
Document that fs::read_dir skips . and ..

Hi,

I think this is worth noting in the docs since it differs from POSIX `readdir`. I didn’t put it under platform-specific notes because it seems to be consistent across platforms, and changing this behavior in the future could cause pretty nasty bugs.

Thanks!
2021-08-08 01:13:44 +09:00
Godmar Back
2a56a4fe54 removed references to parent/child from std::thread documentation
- also clarifies how thread.join and detaching of threads works
- the previous prose implied that there is a relationship between a
spawning thread and the thread being spawned, and that "child" threads
couldn't outlive their parents unless detached, which is incorrect.
2021-08-07 11:33:18 -04:00
Klim Tsoutsman
75e80358d2
Change proc_macro::Diagnostics docs
Add links

Fit 100-character limit
2021-08-07 23:54:34 +10:00
Kornel
7dca8eb565 Use assert_matches! instead of if let {} else 2021-08-07 14:48:27 +01:00
Kornel
215712283f Inline from of TryReserveErrorKind 2021-08-07 13:46:19 +01:00
bors
508b328c39 Auto merge of #87810 - devnexen:haiku_os_simpl, r=Mark-Simulacrum
current_exe haiku code path simplification all of these part of libc
2021-08-07 12:44:09 +00:00
Frank Steffahn
5c30df5954 Fix intra doc link in hidden doc of Iterator::__iterator_get_unchecked 2021-08-07 13:42:15 +02:00
Timotej Lazar
c32e4ba60a
Document that fs::read_dir skips . and .. 2021-08-07 10:14:41 +02:00
bors
996ff2e0a0 Auto merge of #87408 - kornelski:try_reserve_error, r=yaahc
Hide allocator details from TryReserveError

I think there's [no need for TryReserveError to carry detailed information](https://github.com/rust-lang/rust/issues/48043#issuecomment-825139280), but I wouldn't want that issue to delay stabilization of the `try_reserve` feature.

So I'm proposing to stabilize `try_reserve` with a `TryReserveError` as an opaque structure, and if needed, expose error details later.

This PR moves the `enum` to an unstable inner `TryReserveErrorKind` that lives under a separate feature flag. `TryReserveErrorKind` could possibly be left as an implementation detail forever, and the `TryReserveError` get methods such as `allocation_size() -> Option<usize>` or `layout() -> Option<Layout>` instead, or the details could be dropped completely to make try-reserve errors just a unit struct, and thus smaller and cheaper.
2021-08-07 01:26:15 +00:00
bors
db3cb435c1 Auto merge of #87774 - camelid:process-typo, r=jyn514
Fix typo

Add missing "by".
2021-08-06 22:42:25 +00:00
Elichai Turkel
4763ef2bd3
Replace read_to_string with read_line in Stdin example 2021-08-06 20:27:09 +03:00
Yuki Okushi
dba6cb76c2
Rollup merge of #87809 - InnovativeInventor:pointer-typo, r=dtolnay
Fix typo in the ptr documentation

Spotted a minor typo in the docs ;). Pointers are cool!
2021-08-07 01:46:36 +09:00
Yuki Okushi
c5202b3779
Rollup merge of #87787 - hyd-dev:c-unwind, r=RalfJung
Use `C-unwind` ABI for `__rust_start_panic` in `panic_abort`

The function originally has `C` ABI but is called using `C-unwind` ABI in `std`:
d4ad1cfc63/library/std/src/panicking.rs (L49-L54)
Which might be [problematic](https://github.com/rust-lang/miri/pull/1745#discussion_r596096876) and triggers this [Miri error](https://github.com/rust-lang/rust/issues/87778#issuecomment-893306222):
```
error: Undefined Behavior: calling a function with ABI C using caller ABI C-unwind
   --> /home/hyd-dev/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panicking.rs:672:9
    |
672 |         __rust_start_panic(obj)
    |         ^^^^^^^^^^^^^^^^^^^^^^^ calling a function with ABI C using caller ABI C-unwind
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
```
Changing the ABI of the function to `C-unwind` fixes the error above.
2021-08-07 01:46:35 +09:00
bors
4c29cc8fd0 Auto merge of #87777 - the8472:fix-mir-max-rss, r=oli-obk,joshtriplett
Use zeroed allocations in the mir interpreter instead eagerly touching the memory

#86255 introduced a 30% regression in [page faults](https://perf.rust-lang.org/compare.html?start=64ae15ddd3f3cca7036ab2b2f3a6b130b62af4da&end=39e20f1ae5f13451eb35247808d6a2527cb7d060&stat=faults
) and a 3% regression in [max-rss](https://perf.rust-lang.org/index.html?start=2021-07-01&end=&absolute=false&stat=max-rss) in the ctfe-stress benchmarks.
That's most likely happened because it separated allocation from initialization of the vec which defeats the zero-optimization.

Currently there's no allocation API that is fallible, zeroing and returns a slice, so this PR introduces one and then uses that to solve the problem. In principle `vec.resize(len, 0)` could be optimized to use `alloc::grow_zeroed` where appropriate but that would require new specializations and new plumbing in `RawVec`.
2021-08-06 12:11:30 +00:00
David Carlier
5501eba645 current_exe haiku code path simplification all of these part of libc 2021-08-06 10:11:49 +01:00
bors
1f94abcda6 Auto merge of #87808 - JohnTitor:rollup-qqp79xs, r=JohnTitor
Rollup of 9 pull requests

Successful merges:

 - #87561 (thread set_name haiku implementation.)
 - #87715 (Add long error explanation for E0625)
 - #87727 (explicit_generic_args_with_impl_trait: fix min expected number of generics)
 - #87742 (Validate FFI-safety warnings on naked functions)
 - #87756 (Add back -Zno-profiler-runtime)
 - #87759 (Re-use std::sealed::Sealed in os/linux/process.)
 - #87760 (Promote `aarch64-apple-ios-sim` to Tier 2)
 - #87770 (permit drop impls with generic constants in where clauses)
 - #87780 (alloc: Use intra doc links for the reserve function)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-08-06 05:02:35 +00:00
Max Fan
89a8ba46b8 Fix typo in the ptr documentation 2021-08-05 22:50:56 -04:00
Yuki Okushi
b98c388352
Rollup merge of #87780 - est31:intra_doc_links, r=jyn514
alloc: Use intra doc links for the reserve function

The sentence exists to highlight the existence of a
performance footgun of repeated calls of the
reserve_exact function.
2021-08-06 11:21:36 +09:00
Yuki Okushi
13f9a4c309
Rollup merge of #87759 - m-ou-se:linux-process-sealed, r=jyn514
Re-use std::sealed::Sealed in os/linux/process.

This uses `std::sealed::Sealed` in `std::os::linux::process` instead of defining new `Sealed` traits there.
2021-08-06 11:21:33 +09:00
Yuki Okushi
4b068dd657
Rollup merge of #87561 - devnexen:haiku_thread_build_fix, r=yaahc
thread set_name haiku implementation.
2021-08-06 11:21:28 +09:00
bors
7129033b42 Auto merge of #87462 - ibraheemdev:tidy-file-length-ignore-comment, r=Mark-Simulacrum
Ignore comments in tidy-filelength

Ref https://github.com/rust-lang/rust/issues/60302#issuecomment-652402127
2021-08-06 02:07:01 +00:00
The8472
1c21373b50 add Box::try_new_uninit_slice for symmetry 2021-08-05 21:21:52 +02:00
The8472
6ed2d870fc remove cfg gate on use RawVec since it is now also used in fallible code 2021-08-05 19:45:02 +02:00
Mara Bos
cdf83c030a Make rustfmt happy. 2021-08-05 12:55:35 +02:00
Mara Bos
1b318a2b49 Remove unnecessary #[unstable] from internal macro.
After this change, all library #![feature]s enabled in core are for
const fns.
2021-08-05 12:55:35 +02:00
Mara Bos
9decf6365d Remove unused langauge #![feature]s from core. 2021-08-05 12:55:35 +02:00
Mara Bos
37d402eadd Remove unused library #![feature]s from core. 2021-08-05 12:55:35 +02:00
Mara Bos
25d0c58e0a Sort and categorize lint and feature attributes in core. 2021-08-05 12:55:33 +02:00
hyd-dev
7520ea9046
Use C-unwind ABI for __rust_start_panic in panic_abort 2021-08-05 18:01:17 +08:00
est31
1db8737f65 alloc: Use intra doc links for the reserve function
The sentence exists to highlight the existence of a
performance footgun of repeated calls of the
reserve_exact function.
2021-08-05 04:23:54 +02:00
The8472
de91157389 add Box::try_new_zeroed_slice()
Currently there is no API that allows fallible zero-allocation of a Vec.
Vec.try_reserve is not appropriate for this job since it doesn't know
whether it should zero or arbitrary uninitialized memory is fine.

Since Box currently holds most of the zeroing/uninit/slice allocation APIs
it's the best place to add yet another entry into this feature matrix.
2021-08-05 00:23:19 +02:00
bors
25b7648496 Auto merge of #86155 - alexcrichton:abort-on-unwind, r=nikomatsakis
rustc: Fill out remaining parts of C-unwind ABI

This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:

* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
  unwind". This fixes a longstanding soundness issue where if you
  `panic!()` in an `extern "C"` function defined in Rust that's actually
  UB because the LLVM representation for the function has the `nounwind`
  attribute, but then you unwind.

* Whether or not a function unwinds now mainly considers the ABI of the
  function instead of first checking the panic strategy. This fixes a
  miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
  can still unwind.

* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
  reimplemented. Previously this was done as a small tweak during MIR
  generation, but this has been moved to a separate and dedicated MIR
  pass. This new pass will, for appropriate functions and function
  calls, insert a `cleanup` landing pad for any function call that may
  unwind within a function that is itself not allowed to unwind. Note
  that this subtly changes some behavior from before where previously on
  an unwind which was caught-to-abort it would run active destructors in
  the function, and now it simply immediately aborts the process.

* The `#[unwind]` attribute has been removed and all users in tests and
  such are now using `C-unwind` and `#![feature(c_unwind)]`.

I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
2021-08-04 21:09:53 +00:00
Noah Lev
42a417e49a
Fix typo 2021-08-04 14:04:58 -07:00
bors
6fe0886723 Auto merge of #87736 - the8472:inline-advance-by, r=Mark-Simulacrum
#[inline] slice::Iter::advance_by

https://github.com/rust-lang/rust/pull/87387#issuecomment-891942661 was marked as a regression. One of the methods in the PR was missing an inline annotation unlike all the other methods on slice iterators.

Let's see if that makes a difference.
2021-08-04 15:39:20 +00:00
bors
7f3dc04644 Auto merge of #87150 - rusticstuff:simplify_wrapping_neg, r=m-ou-se
Make wrapping_neg() use wrapping_sub(), #[inline(always)]

This is a follow-up change to the fix for #75598. It simplifies the implementation of wrapping_neg() for all integer types by just calling 0.wrapping_sub(self) and always inlines it. This leads to much less assembly code being emitted for opt-level≤1 and thus much better performance for debug-compiled code.

Background is [this discussion on the internals forum](https://internals.rust-lang.org/t/why-does-rust-generate-10x-as-much-unoptimized-assembly-as-gcc/14930).
2021-08-04 12:58:31 +00:00
Mara Bos
f280a126b2 Re-use std::sealed::Sealed in os/linux/process. 2021-08-04 14:15:05 +02:00
bors
71ff9b41e9 Auto merge of #87712 - est31:line-column-1-based, r=petrochenkov
Proc macro spans: make columns 1 based

This makes proc macro spans consistent with the `column!()` macro as well as `std::panic::Location`, as both are 1-based.

https://github.com/rust-lang/rust/issues/54725#issuecomment-497246753
2021-08-04 04:27:35 +00:00
Yuki Okushi
519c5a24e1
Rollup merge of #87729 - adamgemmell:dev/deprecate-crypto, r=Amanieu
Remove the aarch64 `crypto` target_feature

The subfeatures `aes` or `sha2` should be used instead.

This can't yet be done for ARM targets as some LLVM intrinsics still require `crypto`.

Also update the runtime feature detection tests in `library/std` to mirror the updates in `stdarch`. This also helps https://github.com/rust-lang/rust/issues/86941

r? ``@Amanieu``
2021-08-04 08:05:56 +09:00
Yuki Okushi
af8c99a235
Rollup merge of #87723 - frogtd:patch-3, r=JohnTitor
Use .contains instead of manual reimplementation.

It's also significantly easier to read.
2021-08-04 08:05:55 +09:00
Yuki Okushi
87c820573a
Rollup merge of #87267 - dtolnay:negspace, r=Aaron1011
Remove space after negative sign in Literal to_string

Negative proc macro literal tokens used to be printed with a space between the minus sign and the magnitude. That's because `impl ToString for Literal` used to convert the Literal into a TokenStream, which splits the minus sign into a separate Punct token.

```rust
Literal::isize_unsuffixed(-10).to_string()  // "- 10"
```

This PR updates the ToString impl to directly use `rustc_ast::token::Lit`'s ToString, which matches the way Rust negative numbers are idiomatically written without a space.

```rust
Literal::isize_unsuffixed(-10).to_string()  // "-10"
```
2021-08-04 08:05:50 +09:00
Yuki Okushi
ad74828b50
Rollup merge of #81797 - yoshuawuyts:stream_from_iter, r=dtolnay
Add `core::stream::from_iter`

_Tracking issue: https://github.com/rust-lang/rust/issues/81798_

This_ PR implements `std::stream::from_iter`, as outlined in the _"Converting an Iterator to a Stream"_ section of the [Stream RFC](https://github.com/nellshamrell/rfcs/blob/add-async-stream-rfc/text/0000-async-stream.md#converting-an-iterator-to-a-stream). This function enables converting an `Iterator` to a `Stream` by wrapping each item in the iterator with a `Poll::Ready` instance.

r? `@tmandry`

cc/ `@rust-lang/libs` `@rust-lang/wg-async-foundations`

## Example

Being able to convert from an iterator into a stream is useful when refactoring from iterative loops into a more functional adapter-based style. This is fairly common when using more complex `filter` / `map` / `find` chains. In its basic form this conversion looks like this:

**before**
```rust
let mut output = vec![];
for item in my_vec {
    let out = do_io(item).await?;
    output.push(out);
}
```
**after**
```rust
use std::stream;

let output = stream::from_iter(my_vec.iter())
    .map(async |item| do_io(item).await)
    .collect()?;
```

Having a way to convert an `Iterator` to a `Stream` is essential in enabling this flow.

## Implementation Notes

This PR makes use of `unsafe {}` to pin an item. Currently we're having conversations on the libs stream in Zulip how to bring `pin-project` in as a dependency to `core` so we can omit the `unsafe {}`.

This PR also includes a documentation block which references `Stream::next` which currently doesn't exist in the stdlib (originally included in the RFC and PR, but later omitted because of an unresolved issue). `stream::from_iter` can't stabilize before `Stream` does, and there's still a chance we may stabilize `Stream` with a `next` method. So this PR includes documentation referencing that method, which we can remove as part of stabilization if by any chance we don't have `Stream::next`.

## Alternatives Considered

### `impl IntoStream for T: IntoIterator`

An obvious question would be whether we could make it so every iterator can automatically be converted into a stream by calling `into_stream` on it. The answer is: "perhaps, but it could cause type issues". Types like `std::collections` may want to opt to create manual implementations for `IntoStream` and `IntoIter`, which wouldn't be possible if it was implemented through a catch-all trait.

Possibly an alternative such as `impl IntoStream for T: Iterator` could work, but it feels somewhat restrictive. In the end, converting an iterator to a stream is likely to be a bit of a niche case. And even then, **adding a standalone function to convert an `Iterator` into a `Stream` would not be mutually exclusive with a blanket implementation**.

### Naming

The exact name can be debated in the period before stabilization. But I've chosen `stream::from_iter` rather than `stream::iter` because we are _creating a stream from an iterator_ rather than _iterating a stream_. We also expect to add a stream counterpart to `iter::from_fn` later on (blocked on async closures), and having `stream::from_fn` and `stream::from_iter` would feel like a consistent pair. It also has prior art in `async_std::stream::from_iter`.

## Future Directions
### Stream conversions for collections

This is a building block towards implementing `stream/stream_mut/into_stream` methods for `std::collections`, `std::vec`, and more. This would allow even quicker refactorings from using loops to using iterator adapters by omitting the import altogether:

**before**
```rust
use std::stream;

let output = stream::from_iter(my_vec.iter())
    .map(async |item| do_io(item).await)
    .collect()?;
```
**after**
```rust
let output = my_vec
    .stream()
    .map(async |item| do_io(item).await)
    .collect()?;
```
2021-08-04 08:05:50 +09:00
The8472
e44d39a5b7 #[inline] slice::advance_by 2021-08-03 21:32:36 +02:00
Jane Lusby
3d0c5d09d3
Update library/core/src/iter/traits/collect.rs
Co-authored-by: teor <teor@riseup.net>
2021-08-03 12:12:14 -07:00
David Tolnay
3744dc8687
Remove space after negative sign in Literal to_string 2021-08-03 10:40:52 -07:00
Alex Crichton
1c07096a45 rustc: Fill out remaining parts of C-unwind ABI
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:

* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
  unwind". This fixes a longstanding soundness issue where if you
  `panic!()` in an `extern "C"` function defined in Rust that's actually
  UB because the LLVM representation for the function has the `nounwind`
  attribute, but then you unwind.

* Whether or not a function unwinds now mainly considers the ABI of the
  function instead of first checking the panic strategy. This fixes a
  miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
  can still unwind.

* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
  reimplemented. Previously this was done as a small tweak during MIR
  generation, but this has been moved to a separate and dedicated MIR
  pass. This new pass will, for appropriate functions and function
  calls, insert a `cleanup` landing pad for any function call that may
  unwind within a function that is itself not allowed to unwind. Note
  that this subtly changes some behavior from before where previously on
  an unwind which was caught-to-abort it would run active destructors in
  the function, and now it simply immediately aborts the process.

* The `#[unwind]` attribute has been removed and all users in tests and
  such are now using `C-unwind` and `#![feature(c_unwind)]`.

I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
2021-08-03 07:06:19 -07:00
Adam Gemmell
e817b50541 Update aarch64 runtime feature detection tests 2021-08-03 12:07:56 +00:00
Adam Gemmell
f9b168fdd8 Update stdarch to deprecate crypto aarch64 target_feature 2021-08-03 12:07:56 +00:00
Yuki Okushi
423a930c9a
Rollup merge of #87708 - the8472:canonical_v6, r=dtolnay
Add convenience method for handling ipv4-mapped addresses by canonicalizing them

This simplifies checking common properties in an address-family-agnostic
way since #86335 commits to not checking IPv4 semantics
of IPv4-mapped addresses in the `Ipv6Addr` property methods.
2021-08-03 19:07:48 +09:00
Yuki Okushi
5f4cc602fd
Rollup merge of #87685 - notriddle:lazy-from-docs, r=dtolnay
Write docs for SyncOnceCell From and Default impl

Part of #51430
2021-08-03 19:07:45 +09:00
frogtd
499758a285
Use .contains instead of manual reimplementation.
It's also significantly easier to read.
2021-08-03 04:30:44 -04:00
bors
810b9267f3 Auto merge of #86335 - CDirkx:ipv4-in-ipv6, r=dtolnay
Commit to not supporting IPv4-in-IPv6 addresses

Stabilization of the `ip` feature has for a long time been blocked on the question of whether Rust should support handling "IPv4-in-IPv6" addresses: should the various `Ipv6Address` property methods take IPv4-mapped or IPv4-compatible addresses into account. See also the IPv4-in-IPv6 Address Support issue #85609 and #69772 which originally asked the question.

# Overview

In the recent PR #85655 I proposed changing `is_loopback` to take IPv4-mapped addresses into account, so `::ffff:127.0.0.1` would be recognized as a looback address. However, due to the points that came up in that PR, I alternatively propose the following: Keeping the current behaviour and commit to not assigning any special meaning for IPv4-in-IPv6 addresses, other than what the standards prescribe. This would apply to the stable method `is_loopback`, but also to currently unstable methods like `is_global` and `is_documentation` and any future methods. This is implemented in this PR as a change in documentation, specifically the following section:

> Both types of addresses are not assigned any special meaning by this implementation, other than what the relevant standards prescribe. This means that an address like `::ffff:127.0.0.1`, while representing an IPv4 loopback address, is not itself an IPv6 loopback address; only `::1` is. To handle these so called "IPv4-in-IPv6" addresses, they have to first be converted to their canonical IPv4 address.

# Discussion

In the discussion for or against supporting IPv4-in-IPv6 addresses the question what would be least surprising for users of other languages has come up several times. At first it seemed most big other languages supported IPv4-in-IPv6 addresses (or at least considered `::ffff:127.0.0.1` a loopback address). However after further investigation it appears that supporting IPv4-in-IPv6 addresses comes down to how a language represents addresses. .Net and Go do not have a separate type for IPv4 or IPv6 addresses, and do consider `::ffff:127.0.0.1` a loopback address. Java and Python, which do have separate types, do not consider `::ffff:127.0.0.1` a loopback address. Seeing as Rust has the separate `Ipv6Addr` type, it would make sense to also not support IPv4-in-IPv6 addresses. Note that this focuses on IPv4-mapped addresses, no other language handles IPv4-compatible addresses.

Another issue that was raised is how useful supporting these IPv4-in-IPv6 addresses would be in practice. Again with the example of `::ffff:127.0.0.1`, considering it a loopback address isn't too useful as to use it with most of the socket APIs it has to be converted to an IPv4 address anyway. From that perspective it would be better to instead provide better ways for doing this conversion like stabilizing `to_ipv4_mapped` or introducing a `to_canonical` method.

A point in favour of not supporting IPv4-in-IPv6 addresses is that that is the behaviour Rust has always had, and that supporting it would require changing already stable functions like `is_loopback`. This also keeps the documentation of these functions simpler, as we only have to refer to the relevant definitions in the IPv6 specification.

# Decision

To make progress on the `ip` feature, a decision needs to be made on whether or not to support IPv4-in-IPv6 addresses.
There are several options:

- Keep the current implementation and commit to never supporting IPv4-in-IPv6 addresses (accept this PR).
- Support IPv4-in-IPv6 addresses in some/all `IPv6Addr` methods (accept PR #85655).
- Keep the current implementation and but not commit to anything yet (reject both this PR and PR #85655), this entire issue will however come up again in the stabilization of several methods under the `ip` feature.

There are more options, like supporting IPv4-in-IPv6 addresses in `IpAddr` methods instead, but to my knowledge those haven't been seriously argued for by anyone.

There is currently an FCP ongoing on PR #85655. I would ask the libs team for an alternative FCP on this PR as well, which if completed means the rejection of PR #85655, and the decision to commit to not supporting IPv4-in-IPv6 addresses.

If anyone feels there is not enough evidence yet to make the decision for or against supporting IPv4-in-IPv6 addresses, let me know and I'll do whatever I can to resolve it.
2021-08-03 02:18:24 +00:00
est31
7d20789c02 Make the UTF-8 statement more explicit and explicitly test for it 2021-08-03 03:33:05 +02:00
est31
50fcd454c7 Make columns 1 based 2021-08-03 03:10:10 +02:00
The8472
a5cdff3bd4 Add convenience for handling ipv4-mapped addresses by canonicalizing them
This simplifies checking common properties in an address-family-agnostic
way since since #86335 commits to not checking IPv4 semantics
of IPv4-mapped addresses in the `Ipv6Addr` property methods.
2021-08-02 20:28:31 +02:00
Cameron Steffen
7fc26e9665
Rollup merge of #87690 - sharnoff:mut-ptr-allocated-obj-link, r=Mark-Simulacrum
Add missing "allocated object" doc link to `<*mut T>::add`

The portion of the documentation expecting the link was already there, but it was rendered as "[allocated object]". The added reference is just copied from the documentation for `<*const T>::add`.
2021-08-02 09:36:55 -05:00
Cameron Steffen
b1166e14b6
Rollup merge of #87654 - jesyspa:issue-87238-option-result-doc, r=scottmcm
Add documentation for the order of Option and Result

This resolves issue #87238.
2021-08-02 09:36:50 -05:00
Stein Somers
7b28036c63 BTree: merge the complication introduced by #81486 and #86031 2021-08-02 13:23:24 +02:00
bors
b53a93db2d Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
sharnoff
12d199be77
Add missing "allocated object" doc link 2021-08-01 19:48:26 -07:00
bors
effea9a2a0 Auto merge of #87689 - JohnTitor:rollup-ns38b56, r=JohnTitor
Rollup of 13 pull requests

Successful merges:

 - #86183 (Change environment variable getters to error recoverably)
 - #86439 (Remove `Ipv4Addr::is_ietf_protocol_assignment`)
 - #86509 (Move `os_str_bytes` to `sys::unix`)
 - #86593 (Partially stabilize `const_slice_first_last`)
 - #86936 (Add documentation for `Ipv6MulticastScope`)
 - #87282 (Ensure `./x.py dist` adheres to `build.tools`)
 - #87468 (Update rustfmt)
 - #87504 (Update mdbook.)
 - #87608 (Remove unused field `Session.system_library_path`)
 - #87629 (Consistent spelling of "adapter" in the standard library)
 - #87633 (Update compiler_builtins to fix i128 shift/mul on thumbv6m)
 - #87644 (Recommend `swap_remove` in `Vec::remove` docs)
 - #87653 (mark a UB doctest as no_run)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-08-02 02:33:16 +00:00
Yuki Okushi
0851841970
Rollup merge of #87653 - RalfJung:dont-run-ub, r=kennytm
mark a UB doctest as no_run

See https://github.com/rust-lang/rust/pull/87547#discussion_r680334117
Cc `@GuillaumeGomez` `@kennytm`
2021-08-02 11:03:31 +09:00
Yuki Okushi
0c9b35b8c7
Rollup merge of #87644 - Flying-Toast:vec-remove-note, r=the8472
Recommend `swap_remove` in `Vec::remove` docs

I was able to increase the performance (by 20%!) of my project by changing a `Vec::remove` call to `Vec::swap_remove` in a hot function. I think we should explicitly put a note in the Vec::remove docs to guide people in the right direction so they don't make a similar oversight.
2021-08-02 11:03:30 +09:00
Yuki Okushi
87c143661c
Rollup merge of #87629 - steffahn:consistent_adapter_spelling, r=m-ou-se
Consistent spelling of "adapter" in the standard library

Change all occurrences of "(A|a)daptor" to "(A|a)dapter".

The spelling “adapter” seems to be significantly more common both in general in the English language and also in the `rust` repository and standard library. I don’t like the inconsistency that’s currently found on pages like https://doc.rust-lang.org/std/iter/trait.Iterator.html. Note however that the Rust book consistently uses the spelling “iterator adaptor”.

Related discussion [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/adapter.20.2F.20adaptor) ([in the archive](https://zulip-archive.rust-lang.org/219381tlibs/60284adapteradaptor.html)).

`@rustbot` label T-libs
2021-08-02 11:03:28 +09:00
Yuki Okushi
f386ae3533
Rollup merge of #86936 - CDirkx:ipv6-multicast, r=JohnTitor
Add documentation for `Ipv6MulticastScope`

Adds basic documentation to the unstable `Ipv6MulticastScope`, as well as marking it `#[non_exhaustive]` because future IETF RFCs may introduce additional scopes. The documentation mentions this in a section "Stability Guarantees":

> /// Not all possible values for a multicast scope have been assigned.
/// Future RFCs may introduce new scopes, which will be added as variants to this enum;
/// because of this the enum is marked as `#[non_exhaustive]`.
2021-08-02 11:03:22 +09:00
Yuki Okushi
77d568344f
Rollup merge of #86593 - jhpratt:stabilize-const_slice_first_last, r=m-ou-se
Partially stabilize `const_slice_first_last`

This stabilizes the non-`mut` methods of `const_slice_first_last` as `const`. These methods are trivial to implement and have no blockers that I am aware of.

`@rustbot` label +A-const-fn +S-waiting-on-review +T-libs-api
2021-08-02 11:03:21 +09:00
Yuki Okushi
1176d306cd
Rollup merge of #86509 - CDirkx:os_str, r=m-ou-se
Move `os_str_bytes` to `sys::unix`

Followup to #84967, with `OsStrExt` and `OsStringExt` moved out of `sys_common`, there is no reason anymore for `os_str_bytes` to live in `sys_common` and not in sys. This pr moves it to the location `sys::unix::os_str` and reuses the code on other platforms via `#[path]` (as is common in `sys`) instead of importing.
2021-08-02 11:03:20 +09:00
Yuki Okushi
a03d6da3ef
Rollup merge of #86439 - CDirkx:ip-protocol-assignment, r=m-ou-se
Remove `Ipv4Addr::is_ietf_protocol_assignment`

This PR removes the unstable method `Ipv4Addr::is_ietf_protocol_assignment`, as I suggested in https://github.com/rust-lang/rust/issues/85612#issuecomment-847863404. The method was added in #60145, as far as I can tell primarily for the implementation of `Ipv4Addr::is_global` (addresses reserved for IETF protocol assignment are not globally reachable unless otherwise specified).

The method was added in 2019, but I haven't been able to find any open-source code using this method so far. I'm also having a hard time coming up with a usecase for specifically this method; knowing that an address is reserved for future protocols doesn't allow you to do much with it, especially since now some of those addresses are indeed assigned to a protocol and have their own behaviour (and might even be defined to be globally reachable, so if that is what you care about it is always more accurate to call `!is_global()`, instead of `is_ietf_protocol_assignment()`).

Because of these reasons, I propose removing the method (or alternatively make it a private helper for `is_global`) and also not introduce `Ipv6Addr::is_ietf_protocol_assignment` and `IpAddr::is_ietf_protocol_assignment` in the future.
2021-08-02 11:03:19 +09:00
Yuki Okushi
016612dc8d
Rollup merge of #86183 - inquisitivecrystal:env-nul, r=m-ou-se
Change environment variable getters to error recoverably

This PR changes the standard library environment variable getter functions to error recoverably (i.e. not panic) when given an invalid value.

On some platforms, it is invalid for environment variable names to contain `'\0'` or `'='`, or for their values to contain `'\0'`. Currently, the standard library panics when manipulating environment variables with names or values that violate these invariants. However, this behavior doesn't make a lot of sense, at least in the case of getters. If the environment variable is missing, the standard library just returns an error value, rather than panicking. It doesn't make sense to treat the case where the variable is invalid any differently from that. See the [internals thread](https://internals.rust-lang.org/t/why-should-std-var-panic/14847) for discussion. Thus, this PR changes the functions to error recoverably in this case as well.

If desired, I could change the functions that manipulate environment variables in other ways as well. I didn't do that here because it wasn't entirely clear what to change them to. Should they error silently or do something else? If someone tells me how to change them, I'm happy to implement the changes.

This fixes #86082, an ICE that arises from the current behavior. It also adds a regression test to make sure the ICE does not occur again in the future.

`@rustbot` label +T-libs
r? `@joshtriplett`
2021-08-02 11:03:15 +09:00
bors
24bbf7ac2f Auto merge of #85272 - ChayimFriedman2:matches-leading-pipe, r=m-ou-se
Allow leading pipe in `matches!()` patterns.

This is allowed in `match` statement, and stated in https://internals.rust-lang.org/t/leading-pipe-in-core-matches/14699/2 that it should be allowed in these macros too.
2021-08-02 00:13:40 +00:00
bors
cd5a90fb14 Auto merge of #86031 - ssomers:btree_lazy_iterator, r=Mark-Simulacrum
BTree: lazily locate leaves in rangeless iterators

BTree iterators always locate both the first and last leaf edge and often only need either one, i.e., whenever they are traversed in a single direction, like in for-loops and in the common use of `iter().next()` or `iter().next_back()` to retrieve the first or last key/value-pair (#62924). It's fairly easy to avoid because the iterators with this disadvantage already are quite separate from other iterators.

r? `@Mark-Simulacrum`
2021-08-01 21:45:30 +00:00
Michael Howell
e0172b380d Write docs for SyncOnceCell From and Default impl 2021-08-01 14:37:38 -07:00
bors
2827db2b13 Auto merge of #87622 - pietroalbini:bump-bootstrap, r=Mark-Simulacrum
Bump bootstrap compiler to 1.55

Changing the cfgs for stdarch is missing, but my understanding is that we don't need to do it as part of this PR?

r? `@Mark-Simulacrum`
2021-08-01 19:04:37 +00:00
bors
4e21ef2a4e Auto merge of #81825 - voidc:pidfd, r=joshtriplett
Add Linux-specific pidfd process extensions (take 2)

Continuation of #77168.
I addressed the following concerns from the original PR:

- make `CommandExt` and `ChildExt` sealed traits
- wrap file descriptors in `PidFd` struct representing ownership over the fd
- add `take_pidfd` to take the fd out of `Child`
- close fd when dropped

Tracking Issue: #82971
2021-08-01 16:45:47 +00:00
Mara Bos
9854d30543 Update const_slice_first_last_not_mut stable version. 2021-08-01 17:25:19 +02:00
Pietro Albini
24f9de5a44 bump bootstrap compiler to 1.55 2021-08-01 11:19:24 -04:00
Anton Golov
40eaab17de Add documentation for the order of Option and Result 2021-08-01 13:59:19 +02:00
Dominik Stolz
2a4d012103 Add dummy FileDesc struct for doc target 2021-08-01 09:45:00 +02:00
bors
f381e77d35 Auto merge of #84662 - dtolnay:unwindsafe, r=Amanieu
Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core

They were previously only available in std::panic, not core::panic.

- https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html
- https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html
- https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html

Where this is relevant: trait objects! Inside a `#![no_std]` library it's otherwise impossible to have a struct holding a trait object, and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind.

```rust
// common library

#![no_std]

pub struct Thing {
    pub(crate) x: &'static (dyn SomeTrait + Send + Sync),
}

pub(crate) trait SomeTrait {...}
```

```rust
// downstream application

fn main() {
    let thing: library::Thing = ...;
    let _ = std::panic::catch_unwind(|| { let _ = thing; });  // does not work :(
}
```

See a4131708e2/src/gradient.rs (L7-L15) for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller, as the `feature = "std"` would become non-additive in that case.

What happens without the UnwindSafe constraints:

```rust
fn main() {
    let gradient = colorous::VIRIDIS;
    let _ = std::panic::catch_unwind(|| { let _ = gradient; });
}
```

```console
error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
   --> src/main.rs:3:13
    |
3   |     let _ = std::panic::catch_unwind(|| { let _ = gradient; });
    |             ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
    |
   ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40
    |
430 | pub fn catch_unwind<F: FnOnce() -> R + UnwindSafe, R>(f: F) -> Result<R> {
    |                                        ---------- required by this bound in `catch_unwind`
    |
    = help: within `Gradient`, the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `Gradient`
    = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient`
    = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]`
```
2021-08-01 02:53:13 +00:00
David Tolnay
d1586fc6bb
Fix unused sync::atomic import on targets without atomics 2021-07-31 17:27:29 -07:00
David Tolnay
96ecaa17a7
Relocate Arc and Rc UnwindSafe impls 2021-07-31 03:57:49 -07:00
Ralf Jung
6aaa8327f9 mark a UB doctest as no_run 2021-07-31 11:37:48 +02:00
bors
6b0b07d41f Auto merge of #87387 - the8472:slice-iter-advance_by, r=scottmcm
Implement advance_by, advance_back_by for slice::{Iter, IterMut}

Part of #77404.

Picking up where #77633 was closed.

I have addressed https://github.com/rust-lang/rust/pull/77633#issuecomment-771842599 by restoring `nth` and `nth_back`. So according to that comment this should already be r=m-ou-se, but it has been sitting for a while.
2021-07-31 05:22:13 +00:00
bors
b289bb7fdf Auto merge of #87488 - kornelski:track-remove, r=dtolnay
Track caller of Vec::remove()

`vec.remove(invalid)` doesn't print a helpful source position:

> thread 'main' panicked at 'removal index (is 99) should be < len (is 1)', **library/alloc/src/vec/mod.rs:1379:13**
2021-07-31 03:00:20 +00:00
Flying-Toast
9a2e3f3a8e Recommend swap_remove in Vec::remove docs 2021-07-30 16:01:49 -04:00
Yuki Okushi
f4dfb76ea1
Rollup merge of #87609 - LukasKalbertodt:improve-array-map-docs, r=m-ou-se
Add docs about performance and `Iterator::map` to `[T; N]::map`

This suboptimal code gen for some usages of array::map got a bit of
attention by multiple people throughout the community. Some cases:

- https://github.com/rust-lang/rust/issues/75243#issuecomment-866051086
- https://github.com/rust-lang/rust/issues/75243#issuecomment-874732134
- https://www.reddit.com/r/rust/comments/oeqqf7/unexpected_high_stack_usage/

My *guess* is that this gets the attention it gets because in JavaScript
(and potentially other languages), a `map` function on arrays is very
commonly used since in those languages, arrays basically take the role
of Rust's iterator. I considered explicitly naming JavaScript in the
first paragraph I added, but I couldn't find precedence of mentioning
other languages in standard library doc, so I didn't add it.

When array::map was stabilized, we still wanted to add docs, but that
somehow did not happen in time. So here we are. Not sure if this sounds
crazy but maybe it is worth considering beta backporting this? Only if
it's not a lot of work, of course! But yeah, stabilized array::map is
already in beta and if this problem is really as big as it sometimes seems,
might be worth having the docs in place when 1.55 is released.

CC ``@CryZe``

r? ``@m-ou-se`` (since you were involved in that discussion and the stabilization)
2021-07-31 04:09:33 +09:00
Yuki Okushi
f7a2a22815
Rollup merge of #87547 - GuillaumeGomez:nonnull-examples, r=kennytm
Add missing examples for NonNull
2021-07-31 04:09:26 +09:00
Yuki Okushi
f6bc738433
Rollup merge of #87385 - Aaron1011:final-enable-semi, r=petrochenkov
Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default

This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default.

To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon.

In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
2021-07-31 04:09:20 +09:00
David Tolnay
60fa568c31
Fix some broken rustdoc links in core::panic documentation 2021-07-30 10:42:20 -07:00
David Tolnay
701e3a45a9
Fix comment referring to formerly-above code 2021-07-30 10:42:19 -07:00
David Tolnay
6d988dc1e3
Fix undocumented unsafe in AssertUnwindSafe impls 2021-07-30 10:42:18 -07:00
David Tolnay
4e17994b2c
Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core 2021-07-30 10:42:15 -07:00
David Tolnay
76e73b74a6
Fix separation of public vs internal parts of Location 2021-07-30 10:40:02 -07:00
David Tolnay
d7c82ba4a1
Split core::panic module to subdirectory 2021-07-30 10:39:56 -07:00
Frank Steffahn
8d2bb9389a Consistent spelling of "adapter" in the standard library
Change all occurrences of "(A|a)daptor" to "(A|a)dapter".
2021-07-30 17:23:07 +02:00
Guillaume Gomez
1bbe6188d2 Add missing examples for NonNull 2021-07-30 11:30:34 +02:00
Yuki Okushi
84e18828d4
Rollup merge of #87602 - wesleywiser:partially_fix_short_backtraces_windows_optimized, r=dtolnay
[backtraces]: look for the `begin` symbol only after seeing `end`

On `x86_64-pc-windows-msvc`, we often get backtraces which look like
    this:

    ```
    10:     0x7ff77e0e9be5 - std::panicking::rust_panic_with_hook
    11:     0x7ff77e0e11b4 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
    12:     0x7ff77e0e116f - std::sys_common::backtrace::__rust_end_short_backtrace::h61c7ecb1b55338ae
    13:     0x7ff77e0f89dd - std::panicking::begin_panic::h8e60ef9f82a41805
    14:     0x7ff77e0e108c - d
    15:     0x7ff77e0e1069 - c
    16:     0x7ff77e0e1059 - b
    17:     0x7ff77e0e1049 - a
    18:     0x7ff77e0e1039 - core::ptr::drop_in_place<std::rt::lang_start<()>::{{closure}}>::h1bfcd14d5e15ba81
    19:     0x7ff77e0e1186 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
    20:     0x7ff77e0e100c - std::rt::lang_start::{{closure}}::ha054184bbf9921e3
    ```

Notice that `__rust_begin_short_backtrace` appears on frame 11 before
    `__rust_end_short_backtrace` on frame 12. This is because in typical
    release binaries without debug symbols, dbghelp.dll, which we use to walk
    and symbolize the stack, does not know where CGU internal functions
    start or end and so the closure invoked by `__rust_end_short_backtrace`
    is incorrectly described as `__rust_begin_short_backtrace` because it
    happens to be near that symbol.

While that can obviously change, this has been happening quite
    consistently since #75048. Since this is a very small change to the std
    and the change makes sense by itself, I think this is worth doing.

This doesn't completely resolve the situation for release binaries on
    Windows, since without debug symbols, the stack printed can still show
    incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
    does slightly improve the situation in that you see the same backtrace
    you would see with `RUST_BACKTRACE=full` or in a debugger (without the
    uninteresting bits at the top and bottom).

Fixes part of #87481
2021-07-30 16:27:01 +09:00
Yuki Okushi
0180d4ca07
Rollup merge of #87594 - devnexen:netbsd_fs_getfiledescriptor_path, r=joshtriplett
fs File get_path procfs usage for netbsd same as linux.
2021-07-30 16:27:00 +09:00
Yuki Okushi
6e61383b66
Rollup merge of #87585 - GuillaumeGomez:char-types-doc, r=joshtriplett
Add missing links for core::char types
2021-07-30 16:26:59 +09:00
Yuki Okushi
3bc6c28376
Rollup merge of #87574 - cuviper:retain-examples, r=joshtriplett
Update the examples in `String` and `VecDeque::retain`

The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.

[confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858
2021-07-30 16:26:57 +09:00
Yuki Okushi
fd79e7740b
Rollup merge of #87522 - frogtd:patch-1, r=yaahc
Fix assert in diy_float

The shifting should have gone the other way, the current incarnation is always true.
2021-07-30 16:26:53 +09:00
Yuki Okushi
c25b979db6
Rollup merge of #87052 - phlopsi:patch-1, r=jyn514
Optimize fmt::PadAdapter::wrap

After adding the first `write!` usage to my project and printing the result to the console, I noticed, that my binary contains the strings "called `Option::unwrap()` on a `None` value`" and more importantly "C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs", with my release build being configured as follows:
```
[profile.release]
panic = "abort"
codegen-units = 1
strip = "symbols" # the important bit
lto = true
```
I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`.

Aside from me suspecting this function to be the culprit, the replaced code performs the same operation as `Option::insert`, but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore, it makes sense to me to use the more optimized version, instead.

As I don't change any semantics, I hope a simple pull request suffices.
2021-07-30 16:26:52 +09:00
bors
fe1c942eee Auto merge of #87445 - amalik18:issue-83584-fix, r=kennytm
Fix may not to appropriate might not or must not

I went through and changed occurrences of `may not` to be more explicit with `might not` and `must not`.
2021-07-30 04:34:13 +00:00
Lukas Kalbertodt
5cc7702bde
Add docs about performance and Iterator::map to [T; N]::map 2021-07-30 00:08:48 +02:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
Wesley Wiser
286cdc81a8 [backtraces]: look for the begin symbol only after seeing end
On `x86_64-pc-windows-msvc`, we often get backtraces which look like
this:

```
10:     0x7ff77e0e9be5 - std::panicking::rust_panic_with_hook
11:     0x7ff77e0e11b4 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
12:     0x7ff77e0e116f - std::sys_common::backtrace::__rust_end_short_backtrace::h61c7ecb1b55338ae
13:     0x7ff77e0f89dd - std::panicking::begin_panic::h8e60ef9f82a41805
14:     0x7ff77e0e108c - d
15:     0x7ff77e0e1069 - c
16:     0x7ff77e0e1059 - b
17:     0x7ff77e0e1049 - a
18:     0x7ff77e0e1039 - core::ptr::drop_in_place<std::rt::lang_start<()>::{{closure}}>::h1bfcd14d5e15ba81
19:     0x7ff77e0e1186 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
20:     0x7ff77e0e100c - std::rt::lang_start::{{closure}}::ha054184bbf9921e3
```

Notice that `__rust_begin_short_backtrace` appears on frame 11 before
`__rust_end_short_backtrace` on frame 12. This is because in typical
release binaries without debug symbols, dbghelp.dll, which we use to walk
and symbolize the stack, does not know where CGU internal functions
start or end and so the closure invoked by `__rust_end_short_backtrace`
is incorrectly described as `__rust_begin_short_backtrace` because it
happens to be near that symbol.

While that can obviously change, this has been happening quite
consistently since #75048. Since this is a very small change to the std
and the change makes sense by itself, I think this is worth doing.

This doesn't completely resolve the situation for release binaries on
Windows, since without debug symbols, the stack printed can still show
incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
does slightly improve the situation in that you see the same backtrace
you would see with `RUST_BACKTRACE=full` or in a debugger (without the
uninteresting bits at the top and bottom).
2021-07-29 13:51:27 -04:00
David Carlier
ce1bd70035 fs File get_path procfs usage for netbsd same as linux. 2021-07-29 17:49:48 +01:00
Ian Jackson
bf30c51541 Rename feature gate bufwriter_into_parts from bufwriter_into_raw_parts
As requested
  https://github.com/rust-lang/rust/pull/85901#pullrequestreview-698404772

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-29 15:23:32 +01:00
Ian Jackson
66f38075af BufWriter: rename into_parts from into_raw_parts
I looked in stdlib and as @BurntSushi thought, `raw` is generally
used for raw pointers, or other hazardous kinds of thing.  stdlib does
not have `into_parts` apart from the one I added to `IntoInnerError`.

I did an ad-hoc search of the rustdocs for my current game project
Otter, which includes quite a large number of dependencies.
`into_parts` seems heavily used for things quite like this.

So change this name.

Suggested-by: Andrew Gallant <jamslam@gmail.com>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-29 15:23:32 +01:00
Ian Jackson
cbba940daf BufWriter: actually export WriterPanicked error
I didn't notice the submodule, which means I failed to re-export this
to make it actually-public.

Reported-by: Andrew Gallant <jamslam@gmail.com>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-29 13:54:16 +01:00
Guillaume Gomez
cf0f5021f4 Add missing links for core::char types 2021-07-29 14:13:41 +02:00
bors
5fb3394cbd Auto merge of #86664 - m-ou-se:uninit-track-caller, r=JohnTitor
Add #[track_caller] for some function in core::mem.

These functions can panic for some types. This makes the panic point to the code that calls e.g. mem::uninitialized(), instead of inside the definition of mem::uninitialized.
2021-07-29 09:35:23 +00:00
bors
6e0a8bf790 Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str, r=oli-obk
Make const panic!("..") work in Rust 2021.

During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.

panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.

r? `@RalfJung`
2021-07-29 07:12:07 +00:00
Ali Malik
ffcf8a0d76 Fix may not to appropriate might not or must not 2021-07-29 01:16:53 -04:00
Ali Malik
e43254aad1 Fix may not to appropriate might not or must not 2021-07-29 01:15:20 -04:00
bors
85237886df Auto merge of #85874 - steffahn:fix_unsound_zip_optimization, r=yaahc
Remove unsound TrustedRandomAccess implementations

Removes the implementations that depend on the user-definable trait `Copy`.

Fixes #85873 in the most straightforward way.

<hr>

_Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577.

With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`.

The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).
2021-07-29 00:31:07 +00:00
Josh Stone
d4a60ab34f Update the examples in String and VecDeque::retain
The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.

[confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858
2021-07-28 16:35:59 -07:00
Yuki Okushi
6c4888a74e
Rollup merge of #87565 - ibraheemdev:patch-7, r=scottmcm
Use backticks when referring to `core::future::Ready` in panic message
2021-07-29 06:11:50 +09:00
Yuki Okushi
87c9f32dc4
Rollup merge of #86839 - D1mon:patch-1, r=JohnTitor
Add doc aliases to fs.rs

Add aliases for create_dir, create_dir_all, remove_dir, remove_dir_all
2021-07-29 06:11:43 +09:00
Yuki Okushi
7c1283a068
Rollup merge of #81363 - jonhoo:no-unpin-in-pin-future-impl, r=m-ou-se
Remove P: Unpin bound on impl Future for Pin

We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.

The `Unpin` bound was originally added in #56939 following the recommendation of ``@withoutboats`` in https://github.com/rust-lang/rust/issues/55766#issue-378417538

That comment does not give explicit justification for why the bound should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
2021-07-29 06:11:42 +09:00
Yuki Okushi
fef1725c0f
Rollup merge of #81050 - yoshuawuyts:stabilize-task-ready, r=m-ou-se
Stabilize core::task::ready!

_Tracking issue: https://github.com/rust-lang/rust/issues/70922_

This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886, this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed.

The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.

r? ``@tmandry``

cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs``

## Example
```rust
use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };

    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}
```
2021-07-29 06:11:41 +09:00
Ibraheem Ahmed
2d8b6e3476
Use backticks when referring to core::future::Ready in panic message 2021-07-28 16:22:34 -04:00
D1mon
387cd6dbf6
Add some doc aliases
Add `mkdir` to `create_dir`, `rmdir` to `remove_dir`.
2021-07-29 04:23:01 +09:00
David Carlier
52371f4b16 thread set_name haiku implementation. 2021-07-28 18:22:19 +01:00
Mara Bos
18cc06c848 Update stable version of ready!() macro. 2021-07-28 16:56:12 +02:00
Mara Bos
f9be6cd898 Add tracking issue number to proc_macro_span_shrink. 2021-07-28 16:34:45 +02:00
Mara Bos
312bf8e0b8 Extend documentation of const_format_args!(). 2021-07-28 16:18:38 +02:00
Mara Bos
0b8033ad8d Improve comments about const panic handling
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-07-28 16:18:38 +02:00
Mara Bos
38bf5b0412 Make const_fmt_args!() work during bootstrap. 2021-07-28 16:12:31 +02:00
Mara Bos
b48274fd98 Use unreachable_unchecked in const_panic_fmt. 2021-07-28 16:12:30 +02:00
Mara Bos
b64c4f9560 Add new const_format_args!() macro and use it in panics. 2021-07-28 16:12:25 +02:00
Mara Bos
f827d3e285 Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.

panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
2021-07-28 16:10:41 +02:00
Mara Bos
3f6dc9a8ab Add #[track_caller] for some function in core::mem.
These functions can panic for some types. This makes the panic point to
the code that calls e.g. mem::uninitialized(), instead of inside the
definition of mem::uninitialized.
2021-07-28 14:34:36 +02:00
Frank Steffahn
6d9c0a16d9 Documentation improvements 2021-07-28 14:33:37 +02:00
Frank Steffahn
89583e98e8 Make SpecInPlaceCollect use TrustedRandomAccessNoCoerce 2021-07-28 14:33:36 +02:00
Frank Steffahn
9ff421da99 Remove redundant bounds on get_unchecked for vec_deque iterators, and run fmt 2021-07-28 14:33:36 +02:00
Frank Steffahn
f9c982c8fd Add back TrustedRandomAccess-specialization for Vec, but only without coercions 2021-07-28 14:33:36 +02:00
Frank Steffahn
bbc6b2691e Change __iterator_get_unchecked to work with TrustedRandomAccessNoCoerce 2021-07-28 14:33:35 +02:00
Frank Steffahn
69dd992f95 Add TrustedRandomAccessNoCoerce supertrait without requirements or guarantees about subtype coercions
Update all the TrustedRandomAccess impls to also implement the new supertrait
2021-07-28 14:33:35 +02:00
Frank Steffahn
1c7f27f792 Improve documentation of TrustedRandomAccess
Include new details regarding coercions to a subtype.
These conditions also explain why the previously removed implementations
for {array, vec, vec_deque}::IntoIter<T> were unsound, because they introduced
an extra `T: Clone` for the TrustedRandomAccess impl, even though their parameter T
is covariant.
2021-07-28 14:33:35 +02:00
Frank Steffahn
a0d8a324eb Remove unsound TrustedRandomAccess implementations
Removes the implementations that depend on the user-definable trait `Copy`.
2021-07-28 14:33:28 +02:00
Yuki Okushi
4ae529688a
Rollup merge of #87523 - frogtd:patch-2, r=dtolnay
Stop creating a reference then immediately dereferencing it.

Stop creating a reference then immediately dereferencing it.
2021-07-28 18:28:22 +09:00
Yuki Okushi
8bc7ec1316
Rollup merge of #87507 - jethrogb:jb/sgx-unmoveable-mutex, r=dtolnay
SGX mutex is *not* moveable

Reverts the erroneous change in #85029.
2021-07-28 18:28:20 +09:00
Yuki Okushi
23479f716a
Rollup merge of #87501 - spastorino:remove-min-tait, r=oli-obk
Remove min_type_alias_impl_trait in favor of type_alias_impl_trait

r? ``@oli-obk``
2021-07-28 18:28:19 +09:00
Yuki Okushi
35dddd3dea
Rollup merge of #87500 - Smittyvb:min-max-docs, r=kennytm
Document math behind MIN/MAX consts on integers

Currently the documentation for `[integer]::{MIN, MAX}` doesn't explain where the constants come from. This documents how the values of those constants are related to powers of 2.
2021-07-28 18:28:18 +09:00
Yuki Okushi
98f7a009fa
Rollup merge of #87330 - inquisitivecrystal:extend-reserve, r=JohnTitor
Use hashbrown's `extend_reserve()` in `HashMap`

When we added `extend_reserve()` to our implementation of `Extend` for `HashMap`, hashbrown didn't have a version we could use. Now that hashbrown has added it, we should use its version instead of implementing it ourself.
2021-07-28 18:28:14 +09:00
bors
aea2e446f0 Auto merge of #86735 - jhpratt:rfc-3107, r=petrochenkov
Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute

This PR implements RFC 3107, which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.
2021-07-28 05:59:30 +00:00
Smitty
0e017496eb remove unneeded stringify 2021-07-27 16:37:18 -04:00
Jacob Pratt
37af399573
Update tests 2021-07-27 16:26:50 -04:00
frogtd
47414aa1bd
Update range.rs
Stop creating a reference then immediately dereferencing it.
2021-07-27 16:14:48 -04:00
Jacob Pratt
7bf791d162
Stabilize const_fn_union 2021-07-27 16:03:33 -04:00
Jacob Pratt
36f02f3523
Stabilize const_fn_transmute 2021-07-27 16:03:09 -04:00
frogtd
b8eb1f167c
Fix assert in diy_float
The shifting should have gone the other way, the current incarnation is always true.
2021-07-27 16:02:35 -04:00
Jacob Pratt
c70147fd66
Permit deriving default on enums with #[default] 2021-07-27 15:47:47 -04:00
Aaron Hill
886dea2bcd
Make SEMICOLON_IN_EXPRESSIONS_FROM_MACROS warn by default 2021-07-27 14:17:37 -05:00
Santiago Pastorino
5bff8429a0
Use type_alias_impl_trait instead of min in compiler and lib 2021-07-27 12:27:08 -03:00
bors
3bc9dd0dd2 Auto merge of #87509 - JohnTitor:rollup-8iqn6cl, r=JohnTitor
Rollup of 10 pull requests

Successful merges:

 - #86450 (Add flag to configure `large_assignments` lint)
 - #86764 (Avoid ICE on type error recovery)
 - #87354 (Update VxWork's UNIX support)
 - #87427 (get rid of NoMirFor error variant)
 - #87446 (macos current_exe using directly libc instead.)
 - #87494 (fix typo: whenver -> whenever)
 - #87497 (Add long explanation for E0544.)
 - #87499 (Remove ASCII fast path from `rustc_lexer::{is_id_continue, is_id_start}`)
 - #87502 (Update cargo)
 - #87503 (Update books)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-07-27 13:31:40 +00:00
Yuki Okushi
7282d71dc2
Rollup merge of #87494 - midgleyc:comment-typos, r=joshtriplett
fix typo: whenver -> whenever

Fix a typo in a comment in RefCell: "whenver" -> "whenever".
2021-07-27 19:52:48 +09:00
Yuki Okushi
988f617f2a
Rollup merge of #87446 - devnexen:macos_update, r=dtolnay
macos current_exe using directly libc instead.
2021-07-27 19:52:47 +09:00
Yuki Okushi
90f6d7becb
Rollup merge of #87354 - Wind-River:2021_master, r=kennytm
Update VxWork's UNIX support

1. VxWorks does not provide glibc
2. VxWorks does provide `sigemptyset` and `sigaddset`

Note: these changes are concurrent to [this PR](https://github.com/rust-lang/libc/pull/2295) in libc.
2021-07-27 19:52:42 +09:00
bors
99d6692f6c Auto merge of #87431 - the8472:array-iter-fold, r=kennytm
implement fold() on array::IntoIter to improve flatten().collect() perf

With #87168 flattening `array::IntoIter`s is now `TrustedLen`, the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features.

This should address the main issue in #87411

```
# old
test vec::bench_flat_map_collect                         ... bench:   2,244,024 ns/iter (+/- 18,903)

# new
test vec::bench_flat_map_collect                         ... bench:     172,863 ns/iter (+/- 2,141)
```
2021-07-27 10:38:41 +00:00
Jethro Beekman
b518dc7a31 Add warning to SGX mutex implementation 2021-07-27 12:13:00 +02:00
Jethro Beekman
eb6f2d4be0 Revert "SGX mutex is movable"
This reverts commit 30b82e0f96.
2021-07-27 12:10:24 +02:00
bors
998cfe5aad Auto merge of #85305 - MarcusDunn:master, r=pnkfelix
Stabilize bindings_after_at

attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490), im pretty new to the whole thing so any pointers are greatly appreciated.
2021-07-27 05:53:31 +00:00
bors
c51607e031 Auto merge of #87062 - poliorcetics:fix-85462, r=dtolnay
Make StrSearcher behave correctly on empty needle

Fix #85462.

This will not affect ABI since the other variant of the enum is bigger.
It may break some code, but that would be very strange: usually people
don't continue after the first `Done` (or `None` for a normal iterator).

`@rustbot` label T-libs A-str A-patterns
2021-07-27 00:31:20 +00:00
Smitty
7abbc6e3c5 Document math behind MIN/MAX consts on integers 2021-07-26 20:22:44 -04:00
The8472
2276c5e3d7 from review: add a comment why try_fold was chosen instead of fold 2021-07-27 00:14:19 +02:00
Chris Midgley
cccd4e2a27 fix typo: whenver -> whenever 2021-07-26 22:12:35 +01:00
Kornel
624df182ea Track caller of Vec::remove() 2021-07-26 18:39:59 +01:00