Commit Graph

1552 Commits

Author SHA1 Message Date
bors
7537b20626 Auto merge of #83948 - ABouttefeux:lint-nullprt-deref, r=RalfJung
add lint deref_nullptr detecting when a null ptr is dereferenced

fixes #83856
changelog: add lint that detect code like
```rust
unsafe {
      &*core::ptr::null::<i32>()
 };
unsafe {
     addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
 --> src\main.rs:5:26
  |
5 |     let x: i32 = unsafe {*core::ptr::null()};
  |                          ^^^^^^^^^^^^^^^^^^
  |                          |
  |                          a null pointer is dereferenced
  |                          this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default
```

Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
2021-04-14 18:04:22 +00:00
Dylan DPC
3d6a364e33
Rollup merge of #84084 - m-ou-se:stabilize-zero, r=scottmcm
Stabilize duration_zero.

FCP here: https://github.com/rust-lang/rust/issues/73544#issuecomment-817201305
2021-04-13 11:10:40 +02:00
Dylan DPC
1cc4b6de3e
Rollup merge of #83707 - exrook:unsafecell, r=m-ou-se
Remove `T: Debug` bound on UnsafeCell Debug impl

Prior art: #65013
2021-04-13 11:10:39 +02:00
bors
23aef90b4e Auto merge of #84086 - m-ou-se:stabilze-is-subnormal, r=dtolnay
Stabilize is_subnormal.

FCP completed here: https://github.com/rust-lang/rust/issues/79288#issuecomment-817201311
2021-04-13 05:59:10 +00:00
bors
7ce470fd9b Auto merge of #84082 - andjo403:stabilize_nonzero_leading_trailing_zeros, r=m-ou-se
Stabilize nonzero_leading_trailing_zeros

Stabilizing nonzero_leading_trailing_zeros and due to this also stabilizing the intrinsic cttz_nonzero

FCP finished here: https://github.com/rust-lang/rust/issues/79143#issuecomment-817216153
`@rustbot` modify labels: +T-libs

Closes #79143
2021-04-13 03:18:10 +00:00
Mara Bos
b44ae964e2 Mark Duration::is_zero as rustc_const_stable. 2021-04-12 16:32:57 +02:00
Mara Bos
d1e23b8af8 Stabilize duration_zero. 2021-04-12 16:32:56 +02:00
bors
d68f7a2f50 Auto merge of #84090 - marmeladema:stabilize-duration-saturating-ops, r=m-ou-se
Stabilize feature `duration_saturating_ops`

FCP here: https://github.com/rust-lang/rust/issues/76416#issuecomment-817201314

Closes #76416

r? `@m-ou-se`
2021-04-12 05:44:25 +00:00
bors
2c56db4e12 Auto merge of #84085 - m-ou-se:stabilize-atomic-fetch-update, r=kennytm
Stabilize atomic_fetch_update methods on AtomicBool and AtomicPtr.

FCP completed here: https://github.com/rust-lang/rust/issues/78639#issuecomment-817201315
2021-04-12 03:13:33 +00:00
Andreas Jonson
12249acdc8 Stabilize nonzero_leading_trailing_zeros 2021-04-11 19:15:55 +02:00
Andreas Jonson
2d99a8650a stabilize const_cttz 2021-04-11 19:13:27 +02:00
marmeladema
7d89148385 Stabilize feature duration_saturating_ops
Closes #76416
2021-04-11 11:34:42 +01:00
Mara Bos
1a62bdbc30 Stabilize is_subnormal. 2021-04-11 11:48:26 +02:00
Mara Bos
d331e5e50c Stabilize atomic_fetch_update methods on AtomicBool and AtomicPtr. 2021-04-11 11:45:46 +02:00
Tomasz Miąsko
60780e438a Remove FixedSizeArray 2021-04-11 00:00:00 +00:00
bors
58f32da346 Auto merge of #84063 - LingMan:patch-1, r=nagisa
Add note about reverting a workaround in the future

The root cause was fixed upstream in LLVM main. This adds a reminder to revert the workaround once the LLVM rustc depends on is new enough. Since I'm not sure how such optimizations get routed to LLVM releases, I used the conservative assumption that it will only show up with LLVM 13.
2021-04-11 10:04:46 +00:00
LingMan
9aa11a128d
Add note about reverting a workaround in the future
The root cause was fixed upstream in LLVM main. This adds a reminder to revert the workaround once the LLVM rustc depends on is new enough. Since I'm not sure how such optimizations get routed to LLVM releases, I used the conservative assumption that it will only show up with LLVM 13.
2021-04-10 18:47:48 +02:00
Ralf Jung
b35ac6949f fix Miri errors in libcore doctests 2021-04-10 11:58:48 +02:00
Dylan DPC
461297e3fd
Rollup merge of #81938 - lukaslueg:stab_peek_mut, r=Amanieu
Stabilize `peekable_peek_mut`

Resolves #78302. Also adds some documentation on `std::iter::Iterator::peekable()` regarding the new method.

The feature was added in #77491 in Nov' 20, which is recently, but the feature seems reasonably small. Never did a stabilization-pr, excuse my ignorance if there is a protocol I'm not aware of.
2021-04-08 20:29:57 +02:00
Dylan DPC
9aed9c1353
Rollup merge of #81764 - jyn514:lint-links, r=GuillaumeGomez
Stabilize `rustdoc::bare_urls` lint

Closes https://github.com/rust-lang/rust/issues/77501. Closes https://github.com/rust-lang/rust/issues/83598.
2021-04-08 20:29:56 +02:00
Dylan DPC
689978c176
Rollup merge of #80733 - steffahn:prettify_pin_links, r=jyn514
Improve links in inline code in `core::pin`.

## Context

So I recently opened #80720. That PR uses HTML-based `<code>foo</code>` syntax in place of `` `foo` `` for some inline code. It looks like usage of `<code>` tags in doc comments is without precedent in the standard library, but the HTML-based syntax has an important advantage:

You can write something like
```
<code>[Box]<[Option]\<T>></code>
```
which becomes: <code>[Box]<[Option]\<T>></code>, whereas with ordinary backtick syntax, you cannot create links for a substring of an inline code block.

## Problem
I recalled (from my own experience) that a way to partially work around this limitation is to do something like
```
[`Box`]`<`[`Option`]`<T>>`
```
which looks like this: [`Box`]`<`[`Option`]`<T>>` _(admitted, it looks even worse on GitHub than in `rustdoc`’s CSS)_.

[Box]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box"
[`Box`]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box"
[Option]: https://doc.rust-lang.org/std/option/enum.Option.html "Option"
[`Option`]: https://doc.rust-lang.org/std/option/enum.Option.html "Option"
[Pin]: https://doc.rust-lang.org/std/pin/struct.Pin.html "Pin"
[&mut]: https://doc.rust-lang.org/std/primitive.reference.html "mutable reference"

So I searched the standard library and found that e.g. the [std::pin](https://doc.rust-lang.org/std/pin/index.html) module documentation uses this hack/workaround quite a bit, with types like <code>[Pin]<[Box]\<T>></code> or <code>[Pin]<[&mut] T>></code>. Although the way they look like in this sentence is what I would like them to look like, not what they currently look.

### Status Quo

Here’s a screenshot of what it currently looks like:
![Screenshot_20210105_202751](https://user-images.githubusercontent.com/3986214/103692608-4a978780-4f98-11eb-9451-e13622b2e3c0.png)

With a few HTML-style code blocks, we can fix all the spacing issues in the above screenshot that are due usage of this hack/workaround of putting multiple code blocks right next to each other being used.

### after d3915c555e:
![Screenshot_20210105_202932](https://user-images.githubusercontent.com/3986214/103692688-6f8bfa80-4f98-11eb-9be5-9b370eaef644.png)

There’s still a problem of inconsistency. Especially in a sentence such as
> A [`Pin<P>`][Pin] where `P: Deref` should be considered as a "`P`-style pointer" to _[...]_

looks weird with the variable `P` having different colors (and `Deref` has a different color from before where it was a link, too). Or compare the difference of <code>[Pin]<[Box]\<T>></code> vs [`Box<T>`][Box] where one time the variable is part of the link and the other time it isn’t.

_Note: Color differences show even **more strongly** when the ayu theme is used, while they are a bit less prominent in the light theme than they are in the dark theme, which is the one used for these screenshots._

This is why I’ve added the next commit
### after ceaeb249a3
![Screenshot_20210105_203113](https://user-images.githubusercontent.com/3986214/103693496-ab738f80-4f99-11eb-942d-29dace459734.png)
pulling all the type parameters out of their links, and also the last commit with clearly visible changes
### after 87ac118ba3
![Screenshot_20210105_203252](https://user-images.githubusercontent.com/3986214/103693625-e5dd2c80-4f99-11eb-91b7-470c37934e7e.png)
where more links are added, removing e.g. the inconsistency with `Deref`’s color in e.g. `P: Deref` that I already mentioned above.

## Discussion

I am aware that this PR may very well be overkill. If for now only the first commit (plus the fix for the `Drop` link in e65385fbfa, the link titles 684edf7a70 as far as they apply, and a few of the line-break changes) are wanted, I can reduce this PR to just those changes. I personally find the rendered result with all these changes very nice though. On the other hand, all these `<code>` tags are not very nice in the source code, I’ll admit.

Perhaps alternative solutions could be preferred, such as `rustdoc` support for merging subsequent inline code blocks so that all the cases that currently use workarounds rendered as [`Box`]`<`[`Option`]`<T>>` automatically become <code>[Box]<[Option]\<T>></code> without any need for further changes. Even in this case, having a properly formatted, better looking example in the standard library docs could help motivate such a change to `rustdoc` by prodiving an example of the expected results and also the already existing alternative (i.e. using `<code>`). On the other hand, `` [`Box`]`<`[`Option`]`<T>>` `` isn’t particularly nice-looking source code either. I’m not even sure if I wouldn’t actually find the version `<code>[Box]<[Option]\<T>></code>` cleaner to read.

`@rustbot` modify labels: T-doc, T-rustdoc
2021-04-08 20:29:54 +02:00
Dylan DPC
a113240b91
Rollup merge of #83689 - estebank:cool-bears-hot-tip, r=davidtwco
Add more info for common trait resolution and async/await errors

* Suggest `Pin::new`/`Box::new`/`Arc::new`/`Box::pin` in more cases
* Point at `impl` and type defs introducing requirements on E0277
2021-04-08 01:01:43 +02:00
bors
ef2ef926a5 Auto merge of #81047 - glittershark:stabilize-cmp-min-max-by, r=kodraus
Stabilize cmp_min_max_by

I would like to propose cmp::{min_by, min_by_key, max_by, max_by_key}
for stabilization.

These are relatively simple and seemingly uncontroversial functions and
have been unchanged in unstable for a while now.

Closes: #64460
2021-04-07 18:02:21 +00:00
lukaslueg
cfe43f9733
Update library/core/src/iter/traits/iterator.rs
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
2021-04-07 18:02:46 +02:00
lukaslueg
4c850f3783
Update library/core/src/iter/traits/iterator.rs
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
2021-04-07 18:02:39 +02:00
Griffin Smith
462f86da9a Stabilize cmp_min_max_by
I would like to propose cmp::{min_by, min_by_key, max_by, max_by_key}
for stabilization.

These are relatively simple and seemingly uncontroversial functions and
have been unchanged in unstable for a while now.
2021-04-07 10:29:04 -04:00
Esteban Küber
dc71166037 Always mention Box::pin when dealing with !Unpin 2021-04-06 19:55:45 -07:00
Aliénore Bouttefeux
389100921a add lint deref_nullptr 2021-04-06 22:01:00 +02:00
lukaslueg
72796a7c36
Merge branch 'master' into stab_peek_mut 2021-04-06 18:23:21 +02:00
lukaslueg
7f32fda78c
Update library/core/src/iter/adapters/peekable.rs
Co-authored-by: Alexander Ronald Altman <alexanderaltman@me.com>
2021-04-06 18:16:02 +02:00
Joshua Nelson
ef4e5b9ecb Rename non_autolinks -> bare_urls 2021-04-05 04:13:34 -04:00
bors
58e7189650 Auto merge of #83858 - joshtriplett:unsafe-cell-always-inline, r=Mark-Simulacrum
Use `#[inline(always)]` on trivial UnsafeCell methods

UnsafeCell is the standard building block for shared mutable data
structures. UnsafeCell should add zero overhead compared to using raw
pointers directly.

Some reports suggest that debug builds, or even builds at opt-level 1,
may not always be inlining its methods. Mark the methods as
`#[inline(always)]`, since once inlined the methods should result in no
actual code other than field accesses.
2021-04-05 06:21:14 +00:00
bors
b1b0a1597c Auto merge of #83819 - AngelicosPhosphoros:issue-73338-fix-partial-eq-impl, r=Mark-Simulacrum
Optimize jumps in PartialOrd le

Closes https://github.com/rust-lang/rust/issues/73338
This change stops default implementation of `le()` method of PartialOrd from generating jumps.
2021-04-05 03:55:09 +00:00
bors
015d2bc3fe Auto merge of #83864 - Dylan-DPC:rollup-78an86n, r=Dylan-DPC
Rollup of 7 pull requests

Successful merges:

 - #80525 (wasm64 support)
 - #83019 (core: disable `ptr::swap_nonoverlapping_one`'s block optimization on SPIR-V.)
 - #83717 (rustdoc: Separate filter-empty-string out into its own function)
 - #83807 (Tests: Remove redundant `ignore-tidy-linelength` annotations)
 - #83815 (ptr::addr_of documentation improvements)
 - #83820 (Remove attribute `#[link_args]`)
 - #83841 (Allow clobbering unsupported registers in asm!)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-04-05 01:26:57 +00:00
bors
35aa636159 Auto merge of #83530 - Mark-Simulacrum:bootstrap-bump, r=Mark-Simulacrum
Bump bootstrap to 1.52 beta

This includes the standard bump, but also a workaround for new cargo behavior around clearing out the doc directory when the rustdoc version changes.
2021-04-04 22:45:56 +00:00
Dylan DPC
fbe89e20e8
Rollup merge of #83815 - RalfJung:addr_of, r=kennytm
ptr::addr_of documentation improvements

While writing https://github.com/rust-lang/reference/pull/1001 I figured I could also improve the docs here a bit.
2021-04-05 00:24:32 +02:00
Dylan DPC
4e3f471499
Rollup merge of #83019 - eddyb:spirv-no-block-swap, r=nagisa
core: disable `ptr::swap_nonoverlapping_one`'s block optimization on SPIR-V.

SPIR-V primarily supports what it calls the "Logical addressing model" (and AFAIK for graphical shaders it's the only option), and what that implies is that there is no "memory" to uniformly address at some byte/word level, and that you can't really talk about values having a "raw representation" in terms of sequences of bytes. Therefore, the "block"-wise swapping optimization employed by `ptr::swap_nonoverlapping_one` (where a "block" is 32 bytes, currently), is fundamentally incompatible with SPIR-V "memory".

As such, [Rust-GPU](https://github.com/EmbarkStudios/rust-gpu/)'s `rustc_codegen_spirv` backend cannot currently allow the use of `ptr::swap_nonoverlapping_one` - but that comes at a great price, since it's the building block of `mem::{swap,replace}`, and those in turn are used by e.g. `Option::take` and `Range`'s `Iterator` implementation (the latter blocking the use of `for i in 0..n` loops).

There's 4 options I can see in terms of supporting `ptr::swap_nonoverlapping_one` in `rustc_codegen_spirv`:
* legalize the block-wise swap loop back into swapping whole values, for SPIR-V
  * this is made borderline impossible by the fact that the size of the state "on the stack" is a block, and has to be expanded back to the appropriate size of the value being swapped, so in practice this would have to effectively pattern-match on the exact shape of the block-wise swapping algorithm, as a roundabout way of "patching `core::ptr` on the fly"
* (**this PR**) disable the block-wise swap optimization altogether when `#[cfg(target_arch = "spirv")`
  * I've tested it and it does in fact allow compiling `for i in 0..n` loops, which was my primary motivation
  * main downside IMO is the fact that `core` now acknowledges an out-of-tree backend
    * as a counterpoint, any attempt to compile Rust to SPIR-V would run into this problem, one way or another
* only enable the block-wise swap optimization on targets where it's been empirically proven to be an improvement
  * would avoid any surprises in terms of potentially-broken/inefficient codegen, in general
  * however, it may be universally applicable (thanks to caches), even if the optimal block size could differ
* move low-level swapping into an intrinsic, where the backend can choose any optimization approach it wants
  * this also has an impact on MIR optimizations (cc ``@rust-lang/wg-mir-opt)`` - which currently cannot hope to make sense of e.g. `Option::take` despite it being effectively `_0 = *_1;` `*_1 = None;` `return;`
  * long-term this is my preferred approach, and I can start working on it if that's desired, but I wanted to confirm that this swapping optimization is the final blocker for [Rust-GPU](https://github.com/EmbarkStudios/rust-gpu/) supporting e.g. range `for` loops

r? ``@nagisa`` cc ``@rust-lang/libs``
2021-04-05 00:24:29 +02:00
Eduard-Mihai Burtescu
bc6af97ed0 core: disable ptr::swap_nonoverlapping_one's block optimization on SPIR-V. 2021-04-04 22:26:27 +03:00
Eduard-Mihai Burtescu
3c3d3ddde9 core: rearrange ptr::swap_nonoverlapping_one's cases (no functional changes). 2021-04-04 22:26:00 +03:00
Mark Rousskov
b3a4f91b8d Bump cfgs 2021-04-04 14:57:05 -04:00
Josh Triplett
37498a19de Use #[inline(always)] on trivial UnsafeCell methods
UnsafeCell is the standard building block for shared mutable data
structures. UnsafeCell should add zero overhead compared to using raw
pointers directly.

Some reports suggest that debug builds, or even builds at opt-level 1,
may not always be inlining its methods. Mark the methods as
`#[inline(always)]`, since once inlined the methods should result in no
actual code other than field accesses.
2021-04-04 11:55:13 -07:00
AngelicosPhosphoros
ed0d8fa3e8 Optimize PartialOrd le
Closes https://github.com/rust-lang/rust/issues/73338
This change stops default implementation of `le()` method from generating jumps.
2021-04-04 20:37:48 +03:00
Ralf Jung
b577d7ef25
fix typo
Co-authored-by: kennytm <kennytm@gmail.com>
2021-04-04 19:32:54 +02:00
Dylan DPC
869726d335
Rollup merge of #81619 - SkiFire13:resultshunt-inplace, r=the8472
Implement `SourceIterator` and `InPlaceIterable` for `ResultShunt`
2021-04-04 19:19:59 +02:00
Ralf Jung
5d1747bf07
rely on intra-doc links
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
2021-04-04 11:24:25 +02:00
Ralf Jung
b93137a24e explain that even addr_of cannot deref a NULL ptr 2021-04-03 19:26:54 +02:00
Ralf Jung
a4a6bdd337 addr_of_mut: add example for creating a pointer to uninit data 2021-04-03 19:25:11 +02:00
bors
5662d9343f Auto merge of #80965 - camelid:rename-doc-spotlight, r=jyn514
Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`

Fixes #80936.

"spotlight" is not a very specific or self-explaining name.
Additionally, the dialog that it triggers is called "Notable traits".
So, "notable trait" is a better name.

* Rename `#[doc(spotlight)]` to `#[doc(notable_trait)]`
* Rename `#![feature(doc_spotlight)]` to `#![feature(doc_notable_trait)]`
* Update documentation
* Improve documentation

r? `@Manishearth`
2021-04-02 07:04:58 +00:00
Jacob Hughes
58218f6c27 Remove T: Debug bound on UnsafeCell Debug impl 2021-03-31 12:11:36 -04:00
Dylan DPC
5b67543c98
Rollup merge of #83579 - RalfJung:ptr-arithmetic, r=dtolnay
Improve pointer arithmetic docs

* Add slightly more detailed definition of "allocated object" to the module docs, and link it from everywhere.
* Clarify the "remains attached" wording a bit (at least I hope this is clearer).
* Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct.

As usual, the edit needs to be done in a dozen places to remain consistent, I hope I got them all.
2021-03-30 11:34:26 +02:00