Skip to content

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Oct 31, 2020

Successful merges:

Failed merges:

r? @ghost

tspiteri and others added 16 commits September 23, 2020 12:01
With this commit, the examples for exp_m1 would fail if x.exp() - 1.0
is used instead of x.exp_m1().
With this commit, the examples for ln_1p would fail if (x + 1.0).ln()
is used instead of x.ln_1p().
- BTreeMap::len
- BTreeMap::is_empty
- BTreeSet::len
- BTreeSet::is_empty
… r=KodrAus

Add std::panic::panic_any.

The discussion of rust-lang#67984 lead to the conclusion that there should be a macro or function separate from `std::panic!()` for throwing arbitrary payloads, to make it possible to deprecate or disallow (in edition 2021) `std::panic!(arbitrary_payload)`.

Alternative names:

- `panic_with!(..)`
- ~~`start_unwind(..)`~~ (panicking doesn't always unwind)
- `throw!(..)`
- `panic_throwing!(..)`
- `panic_with_value(..)`
- `panic_value(..)`
- `panic_with(..)`
- `panic_box(..)`
- `panic(..)`

The equivalent (private, unstable) function in `libstd` is called `std::panicking::begin_panic`.

I suggest `panic_any`, because it allows for any (`Any + Send`) type.

_Tracking issue: #78500_
make exp_m1 and ln_1p examples more representative of use

With this PR, the examples for `exp_m1` would fail if `x.exp() - 1.0` is used instead of `x.exp_m1()`, and the examples for `ln_1p` would fail if `(x + 1.0).ln()` is used instead of `x.ln_1p()`.
Strip tokens from trait and impl items before printing AST JSON

Fixes rust-lang#78510
x.py setup: Create config.toml in the current directory, not the top-level directory

See rust-lang#78509 for discussion.

r? @pnkfelix
cc @cuviper @Mark-Simulacrum
Use SOCK_CLOEXEC and accept4() on more platforms.

This PR enables the use of `SOCK_CLOEXEC` and `accept4` on more platforms.

-----

Android uses the linux kernel, so it should also support it.

DragonflyBSD introduced them in 4.4 (December 2015):
https://www.dragonflybsd.org/release44/

FreeBSD introduced them in 10.0 (January 2014):
https://wiki.freebsd.org/AtomicCloseOnExec

Illumos introduced them in a commit in April 2013, not sure when it was released. It is quite possible that is has always been in Illumos:
illumos/illumos-gate@5dbfd19
https://illumos.org/man/3socket/socket
https://illumos.org/man/3socket/accept4

NetBSD introduced them in 6.0 (Oktober 2012) and 8.0 (July 2018):
https://man.netbsd.org/NetBSD-6.0/socket.2
https://man.netbsd.org/NetBSD-8.0/accept.2

OpenBSD introduced them in 5.7 (May 2015):
https://man.openbsd.org/socket https://man.openbsd.org/accept
Constantify more BTreeMap and BTreeSet functions

Just because we can:

- `BTreeMap::len`
- `BTreeMap::is_empty`
- `BTreeSet::len`
- `BTreeSet::is_empty`

Note that I put the `const` under `const_btree_new`, because I don't think their is a need to create another feature flag for that.

cc rust-lang#71835
@m-ou-se
Copy link
Member Author

m-ou-se commented Oct 31, 2020

@bors r+ p=6 rollup=never

@rustbot modify labels: +rollup

@bors
Copy link
Collaborator

bors commented Oct 31, 2020

📌 Commit 6c17d12 has been approved by m-ou-se

@rustbot rustbot added the rollup A PR which is a rollup label Oct 31, 2020
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 31, 2020
@m-ou-se
Copy link
Member Author

m-ou-se commented Oct 31, 2020

One of these PRs failed in a previous rollup. Closing.

@m-ou-se m-ou-se closed this Oct 31, 2020
@m-ou-se m-ou-se deleted the rollup-86oijn2 branch October 31, 2020 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants