Commit Graph

1705 Commits

Author SHA1 Message Date
Yuki Okushi
9085656512
Rollup merge of #78322 - ssomers:btree_no_min_len_at_node_level, r=Mark-Simulacrum
BTreeMap: stop mistaking node::MIN_LEN for a node level constraint

Correcting #77612 that fell into the trap of assuming that node::MIN_LEN is an imposed minimum everywhere, and trying to make it much more clear it is an offered minimum at the node level.

r? @Mark-Simulacrum
2020-10-25 18:43:47 +09:00
Yuki Okushi
3e017c709d
Rollup merge of #78276 - cutsoy:bump-backtrace, r=nagisa
Bump backtrace-rs to enable Mach-O support on iOS.

Related to rust-lang/backtrace-rs#378. Fixes backtraces on iOS that were missing in Rust v1.47.0 after switching to gimli because it only enabled Mach-O support on macOS.
2020-10-25 18:43:44 +09:00
Yuki Okushi
72e02b015e
Rollup merge of #78208 - liketechnik:issue-69399, r=oli-obk
replace `#[allow_internal_unstable]` with `#[rustc_allow_const_fn_unstable]` for `const fn`s

`#[allow_internal_unstable]` is currently used to side-step feature gate and stability checks.
While it was originally only meant to be used only on macros, its use was expanded to `const fn`s.

This pr adds stricter checks for the usage of `#[allow_internal_unstable]` (only on macros) and introduces the `#[rustc_allow_const_fn_unstable]` attribute for usage on `const fn`s.

This pr does not change any of the functionality associated with the use of `#[allow_internal_unstable]` on macros or the usage of `#[rustc_allow_const_fn_unstable]` (instead of `#[allow_internal_unstable]`) on `const fn`s (see https://github.com/rust-lang/rust/issues/69399#issuecomment-712911540).

Note: The check for `#[rustc_allow_const_fn_unstable]` currently only validates that the attribute is used on a function, because I don't know how I would check if the function is a `const fn` at the place of the check. I therefore openend this as a 'draft pull request'.

Closes rust-lang/rust#69399

r? @oli-obk
2020-10-25 18:43:40 +09:00
Jonas Schievink
e3808edeee
Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str, r=Amanieu
Throw core::panic!("message") as &str instead of String.

This makes `core::panic!("message")` consistent with `std::panic!("message")`, which throws a `&str` and not a `String`.

This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String`, which includes compiler-generated panics such as the panics generated for `mem::zeroed()`.

---

Demonstration:

```rust
use std::panic;
use std::any::Any;

fn main() {
    panic::set_hook(Box::new(|panic_info| check(panic_info.payload())));

    check(&*panic::catch_unwind(|| core::panic!("core")).unwrap_err());
    check(&*panic::catch_unwind(|| std::panic!("std")).unwrap_err());
}

fn check(msg: &(dyn Any + Send)) {
    if let Some(s) = msg.downcast_ref::<String>() {
        println!("Got a String: {:?}", s);
    } else if let Some(s) = msg.downcast_ref::<&str>() {
        println!("Got a &str: {:?}", s);
    }
}
```

Before:
```
Got a String: "core"
Got a String: "core"
Got a &str: "std"
Got a &str: "std"
```

After:
```
Got a &str: "core"
Got a &str: "core"
Got a &str: "std"
Got a &str: "std"
```
2020-10-24 22:39:53 +02:00
Jonas Schievink
0a06d7344b
Rollup merge of #78069 - fusion-engineering-forks:core-const-panic-str, r=RalfJung
Fix const core::panic!(non_literal_str).

Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.

This fixes the issue mentioned here: https://github.com/rust-lang/rust/issues/51999#issuecomment-687604248

r? `@RalfJung`

`@rustbot` modify labels: +A-const-eval
2020-10-24 22:39:49 +02:00
Jonas Schievink
e34263d86a
Rollup merge of #77610 - hermitcore:dtors, r=m-ou-se
revise Hermit's mutex interface to support the behaviour of StaticMutex

rust-lang/rust#77147 simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. To support the new behavior of StaticMutex, we move part of the mutex implementation into libstd.

The interface to the OS changed. Consequently, I removed a few functions, which aren't longer needed.
2020-10-24 22:39:44 +02:00
Jonas Schievink
a547055184
Rollup merge of #76614 - NoraCodes:nora/control_flow_enum, r=scottmcm
change the order of type arguments on ControlFlow

This allows ControlFlow<BreakType> which is much more ergonomic for common iterator combinator use cases.

Addresses one component of #75744
2020-10-24 22:39:41 +02:00
Jonas Schievink
01a38f0d9a
Rollup merge of #75115 - chansuke:sys-cloudabi-unsafe, r=KodrAus
`#[deny(unsafe_op_in_unsafe_fn)]` in sys/cloudabi

Partial fix of #73904.

This encloses unsafe operations in unsafe fn in sys/cloudabi.
2020-10-24 22:39:35 +02:00
Stein Somers
3b6c4fe465 BTreeMap: stop mistaking node::MIN_LEN as a node level constraint 2020-10-24 15:24:37 +02:00
Jonas Schievink
eaa982305d
Rollup merge of #78274 - Enet4:patch-1, r=jonas-schievink
Update description of Empty Enum for accuracy

An empty enum is similar to the never type `!`, rather than the unit type `()`.
2020-10-24 14:12:11 +02:00
Jonas Schievink
d9acd7d148
Rollup merge of #78109 - cuviper:exhausted-rangeinc, r=dtolnay
Check for exhaustion in RangeInclusive::contains and slicing

When a range has finished iteration, `is_empty` returns true, so it
should also be the case that `contains` returns false.

Fixes #77941.
2020-10-24 14:12:01 +02:00
Jonas Schievink
d7c635b3a5
Rollup merge of #77392 - Canop:option_insert, r=m-ou-se
add `insert` to `Option`

This removes a cause of `unwrap` and code complexity.

This allows replacing

```
option_value = Some(build());
option_value.as_mut().unwrap()
```

with

```
option_value.insert(build())
```

It's also useful in contexts not requiring the mutability of the reference.

Here's a typical cache example:

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
	Some(e) => &e.content,
	None => {
	    cache = Some(compute_cache_entry());
	    // unwrap is OK because we just filled the option
	    &cache.as_ref().unwrap().content
	}
};
```

It can be changed into

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
	Some(e) => &e.content,
	None => &cache.insert(compute_cache_entry()).content,
};
```

*(edited: I removed `insert_with`)*
2020-10-24 14:11:57 +02:00
Nicolas Nattis
929f80ece9 Add a spin loop hint for Arc::downgrade 2020-10-23 16:10:56 -03:00
Tim
7d30c53656
Bump backtrace-rs to enable Mach-O support on iOS. 2020-10-23 13:47:09 +02:00
Eduardo Pinho
efedcb2344
Update description of Empty Enum for accuracy
An empty enum is similar to the never type `!`, rather than the unit type `()`.
2020-10-23 12:13:07 +01:00
Canop
216d0fe364 add tracking issue number to option_insert feature gate 2020-10-23 11:44:58 +02:00
Canop
415a8e526d Update library/core/src/option.rs
Co-authored-by: Ivan Tham <pickfire@riseup.net>
2020-10-23 11:41:19 +02:00
Canop
39557799c7 Update library/core/src/option.rs
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2020-10-23 11:41:19 +02:00
Canop
cc8b77a7cf fix naming unconsistency between function doc and prototype 2020-10-23 11:41:19 +02:00
Canop
60a96cae33 more tests in option.insert, code cleaning in option
Code cleaning made according to suggestions in discussion
on PR ##77392 impacts insert, get_or_insert and get_or_insert_with.
2020-10-23 11:41:19 +02:00
Canop
e8df2a4269 remove option.insert_with
`option.insert` covers both needs anyway, `insert_with` is
redundant.
2020-10-23 11:41:19 +02:00
Canop
9b90e1762e add insert and insert_with to Option
This removes a cause of `unwrap` and code complexity.

This allows replacing

```
option_value = Some(build());
option_value.as_mut().unwrap()
```

with

```
option_value.insert(build())
```

or

```
option_value.insert_with(build)
```

It's also useful in contexts not requiring the mutability of the reference.

Here's a typical cache example:

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
	Some(e) => &e.content,
	None => {
	    cache = Some(compute_cache_entry());
	    // unwrap is OK because we just filled the option
	    &cache.as_ref().unwrap().content
	}
};
```

It can be changed into

```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
	Some(e) => &e.content,
	None => &cache.insert_with(compute_cache_entry).content,
};
```
2020-10-23 11:41:19 +02:00
Yuki Okushi
dfb0d09bae
Rollup merge of #78163 - camelid:fixup-lib-docs, r=m-ou-se
Clean up lib docs

Cherry-picked out of #78094.
2020-10-23 18:26:33 +09:00
Yuki Okushi
39f8289e38
Rollup merge of #77969 - ryan-scott-dev:bigo-notation-consistency, r=m-ou-se
Doc formating consistency between slice sort and sort_unstable, and big O notation consistency

Updated documentation for slice sorting methods to be consistent between stable and unstable versions, which just ended up being minor formatting differences.

I also went through and updated any doc comments with big O notation to be consistent with #74010 by italicizing them rather than having them in a code block.
2020-10-23 18:26:26 +09:00
Yuki Okushi
b968738348
Rollup merge of #77918 - wcampbell0x2a:cleanup-network-tests, r=m-ou-se
Cleanup network tests

Some cleanup for network related tests
2020-10-23 18:26:22 +09:00
Yuki Okushi
4859786c69
Rollup merge of #77890 - gilescope:welformed-json-output-from-libtest, r=KodrAus
Fixing escaping to ensure generation of welformed json.

doc tests' json name have a filename in them. When json test output is asked for on windows currently produces invalid json.
Tracking issue for json test output: #49359
2020-10-23 18:26:20 +09:00
Yuki Okushi
8e373304ed
Rollup merge of #77339 - fusion-engineering-forks:tryfrom-nonzero-to-nonzero, r=dtolnay
Implement TryFrom between NonZero types.

This will instantly be stable, as trait implementations for stable types and traits can not be `#[unstable]`.

Closes #77258.

@rustbot modify labels: +T-libs
2020-10-23 18:26:16 +09:00
Leonora Tindall
84daccc559 change the order of type arguments on ControlFlow
This allows ControlFlow<BreakType> which is much more ergonomic for
common iterator combinator use cases.
2020-10-22 17:26:48 -07:00
Camelid
13bc087a73 Clean up lib docs 2020-10-22 10:36:35 -07:00
Mara Bos
4f7ffbf351 Fix const core::panic!(non_literal_str). 2020-10-22 18:41:35 +02:00
Yuki Okushi
69e0658f41
Rollup merge of #78200 - LeSeulArtichaut:controlflow-is-meth, r=scottmcm
Add `ControlFlow::is_{break,continue}` methods

r? @scottmcm cc #75744
2020-10-22 09:45:45 +09:00
Yuki Okushi
6bfbc24645
Rollup merge of #78188 - fusion-engineering-forks:static-ref-tracking-issue, r=withoutboats
Add tracking issue number for pin_static_ref

Forgot to add a tracking issue in #77726. Opened #78186 as tracking issue.
2020-10-22 09:45:43 +09:00
varkor
878c97e70c Update to rustc-demangle 0.1.18 2020-10-21 21:11:11 +01:00
varkor
2b9d22d3a9 Update rustc-demangle 2020-10-21 21:05:38 +01:00
LeSeulArtichaut
d25c97a3f8 Add ControlFlow::is_{break,continue} methods 2020-10-21 21:50:08 +02:00
Florian Warzecha
05f4a9a42a
switch allow_internal_unstable const fns to rustc_allow_const_fn_unstable 2020-10-21 20:54:20 +02:00
Mara Bos
51de5908c9 Add tracking issue number for pin_static_ref. 2020-10-21 16:30:41 +02:00
Yuki Okushi
89c98cd6b4
Rollup merge of #78063 - camelid:improve-cannot-multiply-error, r=estebank
Improve wording of "cannot multiply" type error

For example, if you had this code:

    fn foo(x: i32, y: f32) -> f32 {
        x * y
    }

You would get this error:

    error[E0277]: cannot multiply `f32` to `i32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`

However, that's not usually how people describe multiplication. People
usually describe multiplication like how the division error words it:

    error[E0277]: cannot divide `i32` by `f32`
     --> src/lib.rs:2:7
      |
    2 |     x / y
      |       ^ no implementation for `i32 / f32`
      |
      = help: the trait `Div<f32>` is not implemented for `i32`

So that's what this change does. It changes this:

    error[E0277]: cannot multiply `f32` to `i32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`

To this:

    error[E0277]: cannot multiply `i32` by `f32`
     --> src/lib.rs:2:7
      |
    2 |     x * y
      |       ^ no implementation for `i32 * f32`
      |
      = help: the trait `Mul<f32>` is not implemented for `i32`
2020-10-21 13:59:39 +09:00
Yuki Okushi
f8bae8b102
Rollup merge of #78056 - ssomers:btree_chop_up_1, r=dtolnay
BTreeMap: split off most code of remove and split_off

Putting map.rs on a diet, in addition to #77851.
r? @dtolnay
2020-10-21 13:59:37 +09:00
Yuki Okushi
ff3c8cb518
Rollup merge of #77726 - fusion-engineering-forks:static-pin, r=dtolnay
Add Pin::static_ref, static_mut.

This adds `Pin::static_ref` and `Pin::static_mut`, which convert a static reference to a pinned static reference.

Static references are effectively already pinned, as what they refer to has to live forever and can never be moved.

---

Context: I want to update the `sys` and `sys_common` mutexes/rwlocks/condvars to use `Pin<&self>` in their functions, instead of only warning in the unsafety comments that they may not be moved. That should make them a little bit less dangerous to use. Putting such an object in a `static` (e.g. through `sys_common::StaticMutex`) fulfills the requirements about never moving it, but right now there's no safe way to get a `Pin<&T>` to a `static`. This solves that.
2020-10-21 13:59:29 +09:00
Josh Stone
9202fbdbdb Check for exhaustion in SliceIndex for RangeInclusive 2020-10-20 17:18:08 -07:00
bors
f965120ad3 Auto merge of #77244 - ssomers:btree_love_the_leaf_edge, r=Mark-Simulacrum
BTreeMap: more refactoring around edges

Continuation of #77005.

r? `@Mark-Simulacrum`
2020-10-20 23:33:56 +00:00
Guillaume Gomez
adda858356
Rollup merge of #78129 - mbartlett21:patch-1, r=kennytm
Wrapping intrinsics doc links update.

The links in the wrapping intrinsics docs now refer to the `wrapping_*` functions, not the `checked_*` functions.
2020-10-20 21:46:37 +02:00
Stein Somers
76c466a18f BTreeMap: less sharing, more similarity between leaf and internal nodes 2020-10-20 15:13:57 +02:00
Stein Somers
7829e18899 BTreeMap: reuse BoxedNode instances directly instead of their contents 2020-10-20 13:58:11 +02:00
mbartlett21
061cf5363c
Wrapping intrinsics update link
Now refers to `wrapping_*`, not `checked_*` for wrapping intrinsics.
2020-10-20 14:09:01 +10:00
Yuki Okushi
6df79bf8a8
Rollup merge of #77923 - wcampbell0x2a:cleanup-net-module, r=scottmcm
[net] apply clippy lints

Applied helpful clippy lints to the network std library module.
2020-10-20 12:11:04 +09:00
Yuki Okushi
f9db00839e
Rollup merge of #77838 - RalfJung:const-fn, r=kennytm
const keyword: brief paragraph on 'const fn'

`const fn` were mentioned in the title, but called "deterministic functions" which is not their main property (though at least currently it is a consequence of being const-evaluable). This adds a brief paragraph discussing them, also in the hopes of clarifying that they do *not* have any effect on run-time uses.
2020-10-20 12:11:02 +09:00
Yuki Okushi
b09ef114bb
Rollup merge of #77761 - tmiasko:pthread-mutex, r=cuviper
Assert that pthread mutex initialization succeeded

If pthread mutex initialization fails, the failure will go unnoticed unless
debug assertions are enabled. Any subsequent use of mutex will also silently
fail, since return values from lock & unlock operations are similarly checked
only through debug assertions.

In some implementations the mutex initialization requires a memory
allocation and so it does fail in practice.

Assert that initialization succeeds to ensure that mutex guarantees
mutual exclusion.

Fixes #34966.
2020-10-20 12:10:58 +09:00
Yuki Okushi
c5b0a88669
Rollup merge of #77612 - ssomers:btree_cleanup_2, r=Mark-Simulacrum
BTreeMap: test invariants more thoroughly and more readably

r? @Mark-Simulacrum
2020-10-20 12:10:52 +09:00