Commit Graph

2093 Commits

Author SHA1 Message Date
Ariel Davis
003a636e76 Add an example for deriving PartialOrd on enums
For some reason, I always forget which variants are smaller and which
are larger when you derive PartialOrd on an enum. And the wording in the
current docs is not entirely clear to me.

So, I often end up making a small enum, deriving PartialOrd on it, and
then writing a `#[test]` with an assert that the top one is smaller than
the bottom one (or the other way around) to figure out which way the
deriving goes.

So then I figured, it would be great if the standard library docs just
had that example, so if I keep forgetting, at least I can figure it out
quickly by looking at std's docs.
2021-08-20 22:24:22 -04:00
Guillaume Gomez
9b7c771713
Rollup merge of #88031 - ibraheemdev:build-hasher-object-safe, r=m-ou-se
Make `BuildHasher` object safe

Resolves #87991
2021-08-18 19:54:57 +02:00
Deadbeef
b5afa6807b
Constified Default implementations
The libs-api team agrees to allow const_trait_impl to appear in the
standard library as long as stable code cannot be broken (they are
properly gated) this means if the compiler teams thinks it's okay, then
it's okay.

My priority on constifying would be:

	1. Non-generic impls (e.g. Default) or generic impls with no
	   bounds
	2. Generic functions with bounds (that use const impls)
	3. Generic impls with bounds
	4. Impls for traits with associated types

For people opening constification PRs: please cc me and/or oli-obk.
2021-08-17 07:15:54 +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
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
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
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
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
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
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
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
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
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
Frank Steffahn
5c30df5954 Fix intra doc link in hidden doc of Iterator::__iterator_get_unchecked 2021-08-07 13:42:15 +02: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
Max Fan
89a8ba46b8 Fix typo in the ptr documentation 2021-08-05 22:50:56 -04: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
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
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
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
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
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
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
frogtd
499758a285
Use .contains instead of manual reimplementation.
It's also significantly easier to read.
2021-08-03 04:30:44 -04: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
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