Commit Graph

2191 Commits

Author SHA1 Message Date
Guillaume Gomez
eb62779f2d
Rollup merge of #88954 - nbdd0121:panic3, r=oli-obk
Allow `panic!("{}", computed_str)` in const fn.

Special-case `panic!("{}", arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!("{}", arg))` in runtime.

This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999.

`@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn

r? `@oli-obk`
2021-09-17 17:41:19 +02:00
Yuki Okushi
5d14396ed0
Rollup merge of #88887 - fee1-dead:const-deref, r=oli-obk
Const Deref

Implements `const Deref`/`const DerefMut` for `&mut T`, `&T`, `Cow<'_, B>` and `ManuallyDrop<T>`
2021-09-17 14:09:48 +09:00
Manish Goregaokar
5b6285e370
Rollup merge of #88928 - lefth:master, r=Mark-Simulacrum
Document the closure arguments for `reduce`.

See issue #88927.
2021-09-16 10:57:20 -07:00
Manish Goregaokar
cad1efae57
Rollup merge of #88915 - joshlf:patch-4, r=kennytm
`Wrapping<T>` has the same layout and ABI as `T`
2021-09-15 14:57:02 -07:00
Gary Guo
11c0e58c74 Allow panic!("{}", computed_str) in const fn. 2021-09-15 21:56:43 +01:00
Deadbeef
349ac4f6c8
Const Deref 2021-09-15 03:06:53 +00:00
Dan Zwell
6b7f916008 Document the closure arguments for reduce.
Fixes issue #88927.
2021-09-14 14:22:49 +08:00
Joshua Liebow-Feeser
1053a5bb0f
Wrapping<T> has the same layout and ABI as T 2021-09-13 12:39:45 -07:00
Guillaume Gomez
5eb77838ea
Rollup merge of #88722 - WaffleLapkin:unsafe_cell_const_get_mut, r=dtolnay
Make `UnsafeCell::get_mut` const
2021-09-13 21:20:39 +02:00
Joshua Nelson
7b46920218 Fix linkcheck issues
Most of these are because alloc uses `#[lang_item]` to define methods,
but core documents primitives before those methods are available.

- Fix rustdoc-js-std test

  For some reason this change made CStr not show up in the results for
  `str,u8`. Since it still shows up for str, and since it wasn't a great
  match for that query anyway, I think this is ok to let slide.

- Add test that all primitives can be linked to
- Enable `doc(primitive)` in `core` as well
- Add linkcheck exception specifically for Windows

  Ideally this would be done automatically by the linkchecker by
  replacing `\\` with forward slashes, but this PR is already a ton of
  work ...

- Don't forcibly fail linkchecking if there's a broken intra-doc link on Windows

  Previously, it would exit with a hard error if a missing file had `::`
  in it. This changes it to report a missing file instead, which allows
  adding an exception.
2021-09-12 02:30:24 +00:00
Joshua Nelson
69fe39e8a8 Add primitive documentation to libcore
This works by doing two things:
- Adding links that are specific to the crate. Since not all primitive
  items are defined in `core` (due to lang_items), these need to use
  relative links and not intra-doc links.
- Duplicating `primitive_docs` in both core and std. This allows not needing CARGO_PKG_NAME to build the standard library. It also adds a tidy check to make sure they stay the same.
2021-09-12 02:23:08 +00:00
Jubilee
95b50eb662
Rollup merge of #87904 - kpreid:unsize, r=jyn514
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.

I have no particular knowledge of `Unsize`; I have attempted to leave the meaning entirely unchanged but may have missed a nuance.

Markdown preview of the edited documentation:

> All implementations of `Unsize` are provided automatically by the compiler.
> Those implementations are:
>
> - Arrays `[T; N]` implement `Unsize<[T]>`.
> - Types implementing a trait `Trait` also implement `Unsize<dyn Trait>`.
> - Structs `Foo<..., T, ...>` implement `Unsize<Foo<..., U, ...>>` if all of these conditions
>   are met:
>   - `T: Unsize<U>`.
>   - Only the last field of `Foo` has a type involving `T`.
>   - `Bar<T>: Unsize<Bar<U>>`, where `Bar<T>` stands for the actual type of that last field.
2021-09-11 08:23:38 -07:00
Waffle Lapkin
2c30162380
Fill in the tracking issue for #![feature(const_unsafecell_get_mut)] 2021-09-11 00:07:14 +03:00
Fabian Wolff
79adda930f Ignore automatically derived impls of Clone and Debug in dead code analysis 2021-09-09 19:49:07 +02:00
Mark Rousskov
b4e7649d6d Bump stage0 compiler to 1.56 2021-09-08 20:51:05 -04:00
Jack Huey
bd6ce72ece
Rollup merge of #88712 - jhpratt:fix-int_rounding-docs, r=joshtriplett
Fix docs for `uX::checked_next_multiple_of`

Thanks to `@photino` for noticing this [here](https://github.com/rust-lang/rust/issues/88581#issuecomment-913982246).

r? `@joshtriplett`

`@rustbot` label: +A-docs +A-waiting-on-review
2021-09-08 12:24:21 -04:00
Jack Huey
2bbcf929c6
Rollup merge of #88648 - kpreid:option, r=Mark-Simulacrum
Correct “copies” to “moves” in `<Option<T> as From<T>>::from` doc, and other copyediting

The `impl<T> From<T> for Option<T>` has no `Copy` or `Clone` bound, so its operation is guaranteed to be a move. The call site might copy, but the function itself cannot.

Since that would have been a rather small PR, I also reviewed the other documentation in the file and made other improvements (in separate commits): adding periods and commas, linking `Deref::Target`, and clarifying what "a container" is in `FromIterator`.
2021-09-08 12:24:18 -04:00
Jack Huey
b1c782f20b
Rollup merge of #88594 - steffahn:more_symbolic_doc_aliases, r=joshtriplett
More symbolic doc aliases

A bunch of small changes, mostly adding `#[doc(alias = "…")]` entries for symbolic `"…"`.

Also a small change in documentation of `const` keywords.
2021-09-08 12:24:17 -04:00
Waffle
efeb461873 Make UnsafeCell::get_mut const 2021-09-07 16:41:15 +03:00
Jacob Pratt
56bb6f5a25
Fix docs for uX::checked_next_multiple_of 2021-09-07 02:14:04 -04:00
Paul Trojahn
50e5f90c92 Suggest deriving traits if possible
This only applies to builtin derives as I don't think there is a
clean way to get the available derives in typeck.

Closes #85851
2021-09-06 13:18:05 +02:00
Falk Hüffner
d760c33183 Change return type for T::{log,log2,log10} to u32. The value is at
most 128, and this is consistent with using u32 for small values
elsewhere (e.g. BITS, count_ones, leading_zeros).
2021-09-05 17:09:21 +02:00
bors
0961e688fd Auto merge of #88469 - patrick-gu:master, r=dtolnay
Add links in docs for some primitive types

This pull request adds additional links in existing documentation of some of the primitive types.

Where items are linked only once, I have used the `[link](destination)` format. For items in `std`, I have linked directly to the HTML, since although the primitives are in `core`, they are not displayed on `core` documentation. I was unsure of what length I should keep lines of documentation to, so I tried to keep them within reason.

Additionally, I have avoided excessively linking to keywords like `self` when they are not relevant to the documentation. I can add these links if it would be an improvement.

I hope this can improve Rust. Please let me know if there's anything I did wrong!
2021-09-05 01:56:25 +00:00
Kevin Reid
9a3a2a1c37 Clarify what “a container” is in FromIterator<Option<A>> for Option<V> doc. 2021-09-04 11:30:14 -07:00
Kevin Reid
c2f432058c Add sentence punctuation and links in Option docs. 2021-09-04 11:30:14 -07:00
Kevin Reid
34c1fce50b “Moves” instead of “copies” in <Option<T> as From<T>>::from doc.
This implementation has no `Copy` or `Clone` bound, so its operation is
guaranteed to be a move. The call site might copy, but the function
itself cannot.

Also linkify `Some` while we're touching the line anyway.
2021-09-04 11:29:55 -07:00
patrick-gu
7c32b58df2
Fix accidentally deleted part 2021-09-03 17:13:42 -07:00
patrick-gu
529abb2fc0 Add a missing backtick 2021-09-03 17:11:57 -07:00
patrick-gu
911d0cbe80 Remove excessive linking 2021-09-03 17:09:37 -07:00
Mara Bos
e13b9c90c9
Rollup merge of #88610 - m-ou-se:array-into-iter-docs, r=Amanieu
Update outdated docs of array::IntoIter::new.
2021-09-03 13:30:50 +02:00
Mara Bos
01775b6027
Rollup merge of #88579 - ast-ral:master, r=m-ou-se
remove redundant / misplaced sentence from docs

Removes sentence that seems to have drifted down into the examples section. Luckily, someone already added an explanation of what happens with packed structs back into the initial section of the doc entry and this wayward sentence can likely just be deleted.
2021-09-03 13:30:49 +02:00
Mara Bos
80b572b5e5
Rollup merge of #88507 - atsuzaki:slice-fill-maybeuninit-test, r=RalfJung
Add test case for using `slice::fill` with MaybeUninit

Adds test for #87891

Looks alright? `@RalfJung`
Fixes #87891
2021-09-03 13:30:47 +02:00
Mara Bos
cb2be32dbd
Rollup merge of #88202 - azdavis:master, r=jyn514
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-09-03 13:30:46 +02:00
Mara Bos
5ea45f35c0 Update outdated docs of array::IntoIter::new. 2021-09-03 11:24:52 +02:00
Mara Bos
2159c5db63
Rollup merge of #88582 - jhpratt:int_roundings, r=joshtriplett
Implement #88581

See #88581 for details. This API was discussed on Zulip.

`@rustbot` label: +T-libs-api +S-waiting-on-review

r? `@joshtriplett`
2021-09-02 19:10:22 +02:00
Mara Bos
0d105c0e77
Rollup merge of #88560 - klensy:formatter-pad-shrink, r=m-ou-se
`fmt::Formatter::pad`: don't call chars().count() more than one time

First commit merges two branches of match to call chars().count() only once: that should be faster if this method hits place of 3rd (previous) branch, plus quarter shorter.
Second commit fixes some clippy lints while i'm here (should it be separate PR?).
2021-09-02 19:10:18 +02:00
Mara Bos
8fd1bf3323
Rollup merge of #88505 - ibraheemdev:use-unwrap-unchecked, r=kennytm
Use `unwrap_unchecked` where possible
2021-09-02 19:10:14 +02:00
Frank Steffahn
49c680ada0 Add "!" doc alias for std::ops::Not 2021-09-02 17:19:43 +02:00
Jacob Pratt
727a4fc7e3
Implement #88581 2021-09-02 01:53:54 -04:00
ast-ral
9da8e2a2fa remove redundant / misplaced sentence from docs 2021-09-01 20:52:30 -07:00
bors
cc9bb1522e Auto merge of #83342 - Count-Count:win-console-incomplete-utf8, r=m-ou-se
Allow writing of incomplete UTF-8 sequences to the Windows console via stdout/stderr

# Problem
Writes of just an incomplete UTF-8 byte sequence (e.g. `b"\xC3"` or `b"\xF0\x9F"`)  to stdout/stderr with a Windows console attached error with `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` even though further writes could complete the codepoint. This is currently a rare occurence since the [linewritershim](2c56ea38b0/library/std/src/io/buffered/linewritershim.rs) implementation flushes complete lines immediately and buffers up to 1024 bytes for incomplete lines. It can still happen as described in #83258.

The problem will become more pronounced once the developer can switch stdout/stderr from line-buffered to block-buffered or immediate when the changes in the "Switchable buffering for Stdout" pull request (#78515) get merged.

# Patch description
If there is at least one valid UTF-8 codepoint all valid UTF-8 is passed through to the extracted `write_valid_utf8_to_console()` fn. The new code only comes into play if `write()` is being passed a short byte slice comprising an incomplete UTF-8 codepoint. In this case up to three bytes are buffered in the `IncompleteUtf8` struct associated with `Stdout` / `Stderr`. The bytes are accepted one at a time. As soon as an error can be detected `io::ErrorKind::InvalidData, "Windows stdio in console mode does not support writing non-UTF-8 byte sequences"` is returned. Once a complete UTF-8 codepoint is received it is passed to the `write_valid_utf8_to_console()` and the buffer length is set to zero.

Calling `flush()` will neither error nor write anything if an incomplete codepoint is present in the buffer.

# Tests
Currently there are no Windows-specific tests for console writing code at all. Writing (regression) tests for this problem is a bit challenging since unit tests and UI tests don't run in a console and suddenly popping up another console window might be surprising to developers running the testsuite and it might not work at all in CI builds. To just test the new functionality in unit tests the code would need to be refactored. Some guidance on how to proceed would be appreciated.

# Public API changes
* `std::str::verifications::utf8_char_width()` would be exposed as `std::str::utf8_char_width()` behind the "str_internals" feature gate.

# Related issues
* Fixes #83258.
* PR #78515 will exacerbate the problem.

# Open questions
* Add tests?
* Squash into one commit with better commit message?
2021-09-02 03:31:17 +00:00
klensy
f5f489b945 fix clippy lints 2021-09-01 15:52:29 +03:00
klensy
6c9e708f4b fmt::Formatter::pad: don't call chars().count() more than one time 2021-09-01 15:36:57 +03:00
Mara Bos
d31352961c
Rollup merge of #88551 - inquisitivecrystal:unsafe_cell_raw_get, r=m-ou-se
Stabilize `UnsafeCell::raw_get()`

This PR stabilizes the associated function `UnsafeCell::raw_get()`. The FCP has [already completed](https://github.com/rust-lang/rust/issues/66358#issuecomment-899095068). While there was some discussion about the naming after the close of the FCP, it looks like people have agreed on this name. Still, it would probably be best if a `libs-api` member had a look at this and stated whether more discussion is needed.

While I was at it, I added some tests for `UnsafeCell`, because there were barely any.

Closes #66358.
2021-09-01 09:23:31 +02:00
inquisitivecrystal
227e004d3f Add a few tests for UnsafeCell 2021-08-31 16:32:01 -07:00
inquisitivecrystal
06dd4c03a0 Stabilize Iterator::intersperse() 2021-08-31 14:50:18 -07:00
inquisitivecrystal
753dac16ab Stabilize UnsafeCell::raw_get() 2021-08-31 14:44:13 -07:00
Mara Bos
e7a247dba4
Rollup merge of #85017 - clarfonthey:carrying_widening, r=m-ou-se
Add carrying_add, borrowing_sub, widening_mul, carrying_mul methods to integers

This comes in part from my own attempts to make (crude) big integer implementations, and also due to the stalled discussion in [RFC 2417](https://github.com/rust-lang/rfcs/pull/2417). My understanding is that changes like these are best offered directly as code and then an RFC can be opened if there needs to be more discussion before stabilisation. Since all of these methods are unstable from the start, I figured I might as well offer them now.

I tried looking into intrinsics, messed around with a few different implementations, and ultimately concluded that these are "good enough" implementations for now to at least put up some code and maybe start bikeshedding on a proper API for these.

For the `carrying_add` and `borrowing_sub`, I tried looking into potential architecture-specific code and realised that even using the LLVM intrinsics for `addcarry` and `subborrow` on x86 specifically, I was getting exactly the same assembly as the naive implementation using `overflowing_add` and `overflowing_sub`, although the LLVM IR did differ because of the architecture-specific code. Longer-term I think that they would be best suited to specific intrinsics as that would make optimisations easier (instructions like add-carry tend to use implicit flags, and thus can only be optimised if they're done one-after-another, and thus it would make the most sense to have compact intrinsics that can be merged together easily).

For `widening_mul` and `carrying_mul`, for now at least, I simply cast to the larger type and perform arithmetic that way, since we currently have no intrinsic that would work better for 128-bit integers. In the future, I also think that some form of intrinsic would work best to cover that case, but for now at least, I think that they're "good enough" for now.

The main reasoning for offering these directly to the standard library even though they're relatively niche optimisations is to help ensure that the code generated for them is optimal. Plus, these operations alone aren't enough to create big integer implementations, although they could help simplify the code required to do so and make it a bit more accessible for the average implementor.

That said, I 100% understand if any or all of these methods are not desired simply because of how niche they are. Up to you. 🤷🏻
2021-08-31 17:54:52 +02:00
Katherine Philip
5390ea4644 Move to the top of file 2021-08-31 08:28:51 -07:00
Katherine Philip
8cecac2602 Add test case for using slice::fill with MaybeUninit 2021-08-30 13:20:11 -07:00