Commit Graph

4233 Commits

Author SHA1 Message Date
marcusdunn
c2af4cb9a3 added back bindings_after_at as a cfg_attr 2021-06-04 09:42:50 -07:00
marcusdunn
5f9e33f680 removed ref to bindings_after_at 2021-06-04 09:42:50 -07:00
Yuki Okushi
0a12431962
Rollup merge of #85963 - m-ou-se:constructor-type-name, r=yaahc
Show `::{{constructor}}` in std::any::type_name().

Fix #84666

Before:
```
[src/main.rs:6] type_name::<T>() = "playground::Velocity"
[src/main.rs:6] type_name::<T>() = "playground::Velocity"
```

After:
```
[src/main.rs:6] type_name::<T>() = "scratchpad::Velocity::{{constructor}}"
[src/main.rs:6] type_name::<T>() = "scratchpad::Velocity"
```

cc ``@scottmcm``
2021-06-04 13:43:02 +09:00
Yuki Okushi
f6aaf05363
Rollup merge of #85888 - steffahn:fix_internal_trustedrandomaccess_docs, r=Mark-Simulacrum
Fix typo in internal documentation for `TrustedRandomAccess`

`next_back` is a method of DoubleEndedIterator, not Iterator.
2021-06-04 13:42:55 +09:00
Yuki Okushi
df9ea79fc7
Rollup merge of #85717 - fee1-dead:document-cow, r=yaahc
Document `From` impls for cow.rs
2021-06-04 13:42:53 +09:00
bors
f1cee2c60e Auto merge of #85867 - steffahn:remove_unnecessary_specfromiter_impls, r=Mark-Simulacrum
Remove unnecessary SpecFromIter impls

Unless I’m missing something, these `SpecFromIter<&'a T, …> for Vec<T>` implementations were completely unused.
2021-06-03 22:45:14 +00:00
Mara Bos
e3b19e5c25 Add test for issue 84666. 2021-06-03 16:13:45 +02:00
Yuki Okushi
bd18686b5f
Rollup merge of #85877 - est31:intra_doc_links, r=jyn514
Intra doc link-ify a reference to a function
2021-06-03 14:35:34 +09:00
Yuki Okushi
9a06f653f7
Rollup merge of #83362 - SOF3:stab/vecdeque-binary-search, r=m-ou-se
Stabilize `vecdeque_binary_search`

This PR stabilizes the feature `vecdeque_binary_search` as tracked in #78021.

The tracking issue has not received any comments for the past 5 months, and concerns have been raised neither in the RFC rust-lang/rfcs#2997 nor in the tracking issue #78021.
2021-06-03 14:35:27 +09:00
Mara Bos
f717992229 Stabilize VecDeque::partition_point. 2021-06-02 20:55:45 +02:00
Mara Bos
f086f1ec90 Bump vecdeque_binary_search stabilization to 1.54. 2021-06-02 20:51:08 +02:00
SOFe
f51f277d6c Bumped vecdeque_binary_search stabilization version to 1.53.0 2021-06-02 20:50:22 +02:00
SOFe
f7c283c160 Stabilize vecdeque_binary_search 2021-06-02 20:50:15 +02:00
bors
c4f186f0ea Auto merge of #85687 - m-ou-se:new-prelude, r=yaahc
New prelude

RFC: rust-lang/rfcs#3114
Tracking issue: https://github.com/rust-lang/rust/issues/85684
2021-06-02 02:36:44 +00:00
Frank Steffahn
c5233b7d4b Fix typo in internal documentation for TrustedRandomAccess
`next_back` is a method of DoubleEndedIterator, not Iterator.
2021-06-01 13:18:20 +02:00
Guillaume Gomez
f4d3f32f45
Rollup merge of #85826 - jsha:npo, r=joshtriplett
Mention "null pointer optimization" in option docs.

I had seen people discuss "null pointer optimization," but when I tried to find official documentation (using Google), the `std::option` page didn't show up, because it doesn't use that term. Hopefully adding the term will help others find it in the future.
2021-06-01 11:29:44 +02:00
est31
a0228d9b87 Intra doc link-ify a reference to a function 2021-06-01 05:04:48 +02:00
Frank Steffahn
5ea3e733cb Update documentation of SpecFromIter to reflect the removed impls 2021-05-31 21:07:03 +02:00
Frank Steffahn
c902fdca45 Remove unnecessary SpecFromIter impls 2021-05-31 19:18:20 +02:00
bors
6a3dce99f6 Auto merge of #85814 - steffahn:fix_linked_list_itermut_debug, r=m-ou-se
Fix unsoundness of Debug implementation for linked_list::IterMut

Fix #85813, new `marker` field follows the example of `linked_list::Iter`.
2021-05-31 15:22:51 +00:00
bors
dc08641128 Auto merge of #85819 - CDirkx:is_unicast_link_local_strict, r=joshtriplett
Remove `Ipv6Addr::is_unicast_link_local_strict`

Removes the unstable method `Ipv6Addr::is_unicast_link_local_strict` and keeps the behaviour of `Ipv6Addr::is_unicast_link_local`, see also #85604 where I have tried to summarize related discussion so far.

My intent is for `is_unicast_link_local`, `is_unicast_site_local` and `is_unicast_global` to have the semantics of checking if an address has Link-Local, Site-Local or Global scope, see also #85696 which changes the behaviour of `is_unicast_global` and renames these methods to `has_unicast_XXX_scope` to reflect this.

For checking Link-Local scope we currently have two methods: `is_unicast_link_local` and `is_unicast_link_local_strict`. This is because of what appears to be conflicting definitions in [IETF RFC 4291](https://datatracker.ietf.org/doc/html/rfc4291).

From [IETF RFC 4291 section 2.4](https://datatracker.ietf.org/doc/html/rfc4291#section-2.4): "Link-Local unicast" (`FE80::/10`)
```text
Address type         Binary prefix        IPv6 notation   Section
------------         -------------        -------------   -------
Unspecified          00...0  (128 bits)   ::/128          2.5.2
Loopback             00...1  (128 bits)   ::1/128         2.5.3
Multicast            11111111             FF00::/8        2.7
Link-Local unicast   1111111010           FE80::/10       2.5.6
Global Unicast       (everything else)
```

From [IETF RFC 4291 section 2.5.6](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.6): "Link-Local IPv6 Unicast Addresses" (`FE80::/64`)
```text
| 10 bits  |         54 bits         |          64 bits           |
+----------+-------------------------+----------------------------+
|1111111010|           0             |       interface ID         |
+----------+-------------------------+----------------------------+
```

With `is_unicast_link_local` checking `FE80::/10` and `is_unicast_link_local_strict` checking `FE80::/64`.

There is also [IETF RFC 5156 section 2.4](https://datatracker.ietf.org/doc/html/rfc5156#section-2.4) which defines "Link-Scoped Unicast" as `FE80::/10`.

It has been pointed out that implementations in other languages and the linux kernel all use `FE80::/10` (https://github.com/rust-lang/rust/pull/76098#issuecomment-706916840, https://github.com/rust-lang/rust/pull/76098#issuecomment-705928605).

Given all of this I believe the correct interpretation to be the following: All addresses in `FE80::/10` are defined as having Link-Local scope, however currently only the block `FE80::/64` has been allocated for "Link-Local IPv6 Unicast Addresses". This might change in the future however; more addresses in `FE80::/10` could be allocated and those will have Link-Local scope. I therefore believe the current behaviour of `is_unicast_link_local` to be correct (if interpreting it to have the semantics of `has_unicast_link_local_scope`) and `is_unicast_link_local_strict` to be unnecessary, confusing and even a potential source of future bugs:

Currently there is no real difference in checking `FE80::/10` or `FE80::/64`, since any address in practice will be `FE80::/64`. However if an application uses `is_unicast_link_local_strict` to implement link-local (so non-global) behaviour, it will be incorrect in the future if addresses outside of `FE80::/64` are allocated.

r? `@joshtriplett` as reviewer of all the related PRs
2021-05-31 05:03:26 +00:00
Guillaume Gomez
980a4a725e
Rollup merge of #85817 - r00ster91:patch-9, r=dtolnay
Fix a typo

See also: #85737
2021-05-30 21:06:52 +02:00
Guillaume Gomez
b0f2a4c660
Rollup merge of #85801 - WaffleLapkin:master, r=joshtriplett
Add `String::extend_from_within`

This PR adds `String::extend_from_within` function under the `string_extend_from_within` feature gate similar to the [`Vec::extend_from_within`] function.

```rust
// String
pub fn extend_from_within<R>(&mut self, src: R)
where
    R: RangeBounds<usize>;
```

[`Vec::extend_from_within`]: https://github.com/rust-lang/rust/issues/81656
2021-05-30 21:06:51 +02:00
bors
bff138dbd9 Auto merge of #85754 - the8472:revert-83770, r=Mark-Simulacrum
Revert "Auto merge of #83770 - the8472:tra-extend, r=Mark-Simulacrum"

Due to a performance regression that didn't show up in the original perf run
this reverts commit 9111b8ae97 (#83770), reversing
changes made to 9a700d2947.

Since since is expected to have the inverse impact it should probably be rollup=never.

r? `@Mark-Simulacrum`
2021-05-30 04:12:44 +00:00
bors
9a72afa7dd Auto merge of #83772 - jhpratt:revamp-step-trait, r=Mark-Simulacrum
Make `Step` trait safe to implement

This PR makes a few modifications to the `Step` trait that I believe better position it for stabilization in the short term. In particular,

1. `unsafe trait TrustedStep` is introduced, indicating that the implementation of `Step` for a given type upholds all stated invariants (which have remained unchanged). This is gated behind a new `trusted_step` feature, as stabilization is realistically blocked on min_specialization.
2. The `Step` trait is internally specialized on the `TrustedStep` trait, which avoids a serious performance regression.
3. `TrustedLen` is implemented for `T: TrustedStep` as the latter's invariants subsume the former's.
4. The `Step` trait is no longer `unsafe`, as the invariants must not be relied upon by unsafe code (unless the type implements `TrustedStep`).
5. `TrustedStep` is implemented for all types that implement `Step` in the standard library and compiler.
6. The `step_trait_ext` feature is merged into the `step_trait` feature. I was unable to find any reasoning for the features being split; the `_unchecked` methods need not necessarily be stabilized at the same time, but I think it is useful to have them under the same feature flag.

All existing implementations of `Step` will be broken, as it is not possible to `unsafe impl` a safe trait. Given this trait only exists on nightly, I feel this breakage is acceptable. The blanket `impl<T: Step> TrustedLen for T` will likely cause some minor breakage, but this should be covered by the equivalent impl for `TrustedStep`.

Hopefully these changes are sufficient to place `Step` in decent position for stabilization, which would allow user-defined types to be used with `a..b` syntax.
2021-05-30 01:21:39 +00:00
Frank Steffahn
b4dcdb4b47 Improve Debug impls for LinkedList reference iterators to show items 2021-05-30 01:03:34 +02:00
Christiaan Dirkx
c1f0c15382 Remove is_unicast_link_local_strict 2021-05-30 00:32:17 +02:00
r00ster
8d70f40b31
Fix a typo 2021-05-30 00:06:27 +02:00
Frank Steffahn
7d364ad7c4 Fix unsoundness of Debug implementation for linked_list::IterMut 2021-05-29 21:33:31 +02:00
Jacob Hoffman-Andrews
79575a1a8e Mention "null pointer optimization" in option docs. 2021-05-29 09:57:12 -07:00
Mark Rousskov
8c2080886f Write primitive types via array buffers
This allows a more efficient implementation (avoiding a fallback to memmove,
which is not optimal for short writes).

This saves 0.29% on diesel.
2021-05-29 12:52:06 -04:00
Mark Rousskov
92b2894d31 Switch to reserve over extend_from_slice
This is a 0.15% win on diesel.
2021-05-29 12:45:07 -04:00
Mark Rousskov
299ac75894 Specialize single-element writes to buffer
copy_from_slice generally falls back to memcpy/memmove, which is much more expensive
than we need to write a single element in.

This saves 0.26% instructions on the diesel benchmark.
2021-05-29 12:45:07 -04:00
Waffle
23f9b92c5e Add String::extend_from_within
This patch adds `String::extend_from_within` function under the
`string_extend_from_within` feature gate similar to the
`Vec::extend_from_within` function.
2021-05-29 10:36:30 +03:00
ltdk
2a40f2423a Add inherent unchecked_shl, unchecked_shr to integers 2021-05-28 22:54:39 -04:00
bors
18135ec85b Auto merge of #85745 - veber-alex:panic_any, r=m-ou-se
Add #[track_caller] to panic_any

Report the panic location from the user code.

```rust
use std::panic;
use std::panic::panic_any;

fn main() {
    panic::set_hook(Box::new(|panic_info| {
        if let Some(location) = panic_info.location() {
            println!(
                "panic occurred in file '{}' at line {}",
                location.file(),
                location.line(),
            );
        } else {
            println!("panic occurred but can't get location information...");
        }
    }));

    panic_any(42);
}
````

Before:
`panic occurred in file '/rustc/ff2c947c00f867b9f012e28ba88cecfbe556f904/library/std/src/panic.rs' at line 59`

After:
`panic occurred in file 'src/main.rs' at line 17`
2021-05-28 06:08:58 +00:00
bors
1c6868aa21 Auto merge of #84568 - andoriyu:libtest/junit_formatter, r=yaahc
feat(libtest): Add JUnit formatter

tracking issue: https://github.com/rust-lang/rust/issues/85563

Add an alternative formatter to `libtest`. Formatter produces valid xml that later can be interpreted as JUnit report.

Caveats:

- `timestamp` is required by schema, but every viewer/parser ignores it. Attribute is not set to avoid depending on chrono;
- Running all "suits" (unit tests, doc-tests and integration tests) will produce a mess;
- I couldn't find a way to get integration test binary name, so it's just goes by "integration";

Sample output for unit tests (pretty printed by 3rd party tool):
```
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
  <testsuite name="test" package="test" id="0" errors="0" failures="0" tests="13" skipped="1">
    <testcase classname="results::tests" name="test_completed_bad" time="0"/>
    <testcase classname="results::tests" name="suite_started" time="0"/>
    <testcase classname="results::tests" name="suite_ended_ok" time="0"/>
    <testcase classname="results::tests" name="suite_ended_bad" time="0"/>
    <testcase classname="junit::tests" name="test_failed_output" time="0"/>
    <testcase classname="junit::tests" name="test_simple_output" time="0"/>
    <testcase classname="junit::tests" name="test_multiple_outputs" time="0"/>
    <testcase classname="results::tests" name="test_completed_ok" time="0"/>
    <testcase classname="results::tests" name="test_stared" time="0"/>
    <testcase classname="junit::tests" name="test_generate_xml_no_error_single_testsuite" time="0"/>
    <testcase classname="results::tests" name="test_simple_output" time="0"/>
    <testcase classname="test" name="should_panic" time="0"/>
    <system-out/>
    <system-err/>
  </testsuite>
</testsuites>
```

Sample output for integration tests (pretty printed by 3rd party tool):

```
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
  <testsuite name="test" package="test" id="0" errors="0" failures="0" tests="1" skipped="0">
    <testcase classname="integration" name="test_add" time="0"/>
    <system-out/>
    <system-err/>
  </testsuite>
</testsuites>
```

Sample output for Doc-tests (pretty printed by 3rd party tool):

```
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
  <testsuite name="test" package="test" id="0" errors="0" failures="0" tests="1" skipped="0">
    <testcase classname="src/lib.rs" name="(line 2)" time="0"/>
    <system-out/>
    <system-err/>
  </testsuite>
</testsuites>
```
2021-05-27 21:14:55 +00:00
Guillaume Gomez
48706edc56
Rollup merge of #85738 - 370417:opensbd, r=m-ou-se
Rename opensbd to openbsd

OpenBsd was sometimes spelled "opensbd" in the standard library.
2021-05-27 20:08:24 +02:00
Guillaume Gomez
e30192ac5c
Rollup merge of #85730 - Smittyvb:iter-min-max-floats, r=m-ou-se
Mention workaround for floats in Iterator::{min, max}

`Iterator::{min, max}` can't be used with iterators of floats due to NaN issues. This suggests a workaround in the documentation of those functions.
2021-05-27 20:08:21 +02:00
The8472
f72c60a39a Revert "Auto merge of #83770 - the8472:tra-extend, r=Mark-Simulacrum"
Due to a performance regression that didn't show up in the original perf run
this reverts commit 9111b8ae97, reversing
changes made to 9a700d2947.
2021-05-27 18:17:09 +02:00
bors
ea78d1edf3 Auto merge of #85737 - scottmcm:vec-calloc-option-nonzero, r=m-ou-se
Enable Vec's calloc optimization for Option<NonZero>

Someone on discord noticed that `vec![None::<NonZeroU32>; N]` wasn't getting the optimization, so here's a PR 🙃

We can certainly do this in the standard library because we know for sure this is ok, but I think it's also a necessary consequence of documented guarantees like those in https://doc.rust-lang.org/std/option/#representation and https://doc.rust-lang.org/core/num/struct.NonZeroU32.html

It feels weird to do this without adding a test, but I wasn't sure where that would belong.  Is it worth adding codegen tests for these?
2021-05-27 13:05:57 +00:00
Alex Veber
ef13f27bc7 Add #[track_caller] to panic_any 2021-05-27 14:19:47 +03:00
Scott McMurray
04d34a97d1 Enable Vec's calloc optimization for Option<NonZero> 2021-05-26 23:19:35 -07:00
Albert Ford
3cafe2a43f
Rename opensbd to openbsd 2021-05-26 23:17:13 -07:00
bors
9814e83094 Auto merge of #84124 - 12101111:libunwind, r=petrochenkov
libunwind fix and cleanup

Fix:

1. "system-llvm-libunwind" now only skip build-script for linux target
2. workaround from https://github.com/rust-lang/rust/pull/65972 is not needed, upstream fix it in 68c50708d1 ( LLVM 11 )
3. remove code for MSCV and Apple in `compile()`, as they are not used
4. fix https://github.com/rust-lang/rust/issues/69222 , compile c files and cpp files in different config
5. fix conditional compilation for musl target.
6. fix that x86_64-fortanix-unknown-sgx don't link libunwind built in build-script into rlib
2021-05-27 04:08:20 +00:00
Dylan DPC
955e0f42fc
Rollup merge of #85719 - elichai:cstring-into_inner-inline, r=m-ou-se
Add inline attr to CString::into_inner so it can optimize out NonNull checks

It seems that currently if you convert any of the standard library's container to a pointer and then to a NonNull pointer, all will optimize out the NULL check except `CString`(https://godbolt.org/z/YPKW9G5xn),
because for some reason `CString::into_inner` isn't inlined even though it's a private function that should compile into a simple `mov` instruction.

Adding a simple `#[inline]` attribute solves this, code example:
```rust
use std::ffi::CString;
use std::ptr::NonNull;

pub fn cstring_nonull(mut n: CString) -> NonNull<i8> {
    NonNull::new(CString::into_raw(n)).unwrap()
}
```

assembly before:
```asm
__ZN3wat14cstring_nonull17h371c755bcad76294E:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	callq	__ZN3std3ffi5c_str7CString10into_inner17h28ece07b276e2878E
	testq	%rax, %rax
	je	LBB0_2
	popq	%rbp
	retq
LBB0_2:
	leaq	l___unnamed_1(%rip), %rdi
	leaq	l___unnamed_2(%rip), %rdx
	movl	$43, %esi
	callq	__ZN4core9panicking5panic17h92a83fa9085a8f73E
	.cfi_endproc

	.section	__TEXT,__const
l___unnamed_1:
	.ascii	"called `Option::unwrap()` on a `None` value"

l___unnamed_3:
	.ascii	"wat.rs"

	.section	__DATA,__const
	.p2align	3
l___unnamed_2:
	.quad	l___unnamed_3
	.asciz	"\006\000\000\000\000\000\000\000\006\000\000\000(\000\000"
```

Assembly after:
```asm
__ZN3wat14cstring_nonull17h9645eb9341fb25d7E:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	movq	%rdi, %rax
	popq	%rbp
	retq
	.cfi_endproc
```

(Related discussion on zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/NonNull.20From.3CBox.3CT.3E.3E)
2021-05-27 03:02:11 +02:00
Dylan DPC
de1d7dbd0f
Rollup merge of #85689 - m-ou-se:array-intoiter-3, r=estebank
Remove Iterator #[rustc_on_unimplemented]s that no longer apply.

Now that `IntoIterator` is implemented for arrays, all the `rustc_on_unimplemented` for arrays of ranges (e.g. `for _ in [1..3] {}`) no longer apply, since they are now valid Rust.

Separated these from #85670, because we should discuss a potential new (clippy?) lint for these.

Until Rust 1.52, `for _ in [1..3] {}` produced:

```
error[E0277]: `[std::ops::Range<{integer}>; 1]` is not an iterator
 --> src/main.rs:2:14
  |
2 |     for _ in [1..3] {}
  |              ^^^^^^ if you meant to iterate between two values, remove the square brackets
  |
  = help: the trait `std::iter::Iterator` is not implemented for `[std::ops::Range<{integer}>; 1]`
  = note: `[start..end]` is an array of one `Range`; you might have meant to have a `Range` without the brackets: `start..end`
  = note: required by `std::iter::IntoIterator::into_iter`
```

But in Rust 1.53 and later, it compiles fine. It iterates over the array by value, for one iteration with the element `1..3`.

This is probably a mistake, which is no longer caught. Should we have a lint for it? Should Clippy have a lint for it?

cc ```@estebank``` ```@flip1995```

cc https://github.com/rust-lang/rust/issues/84513
2021-05-27 03:02:10 +02:00
Dylan DPC
0c53acc6f8
Rollup merge of #85649 - ChrisDenton:update-cc, r=matthewjasper
Update cc

Recent commits have improved `cc`'s finding of MSVC tools on Windows. In particular it should help to address these issues: #83043 and #43468
2021-05-27 03:02:09 +02:00
Smittyvb
b00f6fc8a1
don't use unneeded closure
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
2021-05-26 20:38:50 -04:00
Smittyvb
7146a05a43
don't use unneeded closure
Co-authored-by: Alphyr <47725341+a1phyr@users.noreply.github.com>
2021-05-26 20:38:43 -04:00