The current docs are a bit inconsistent. First, change all references of "recover" to "catch_unwind" because the function was renamed. Second, consistently use the term "unwind safe" instead of "panic safe", "exception safe" and "recover safe" (all these terms were used previously).
The beta builds are currently failing, unfortunately, due to what is presumably
some odd behavior with our makefiles. The wrong bootstrap key is being used to
generate the stage1 cross-compiled libraries, which fails the build.
Interestingly enough if the targets are directly specified as part of the build
then it works just fine! Just a bare `make` fails...
Instead of trying to understand what's happening in the makefiles instead just
tweak how we configure the bootstrap key in a way that's more likely to work.
Add --enable-local-rebuild to bootstrap from the current release
In Linux distributions, it is often necessary to rebuild packages for cases like applying new patches or linking against new system libraries. In this scenario, the rustc in the distro build environment may already match the current release that we're trying to rebuild. Thus we don't want to use the prior release's bootstrap key, nor `--cfg stage0` for the prior unstable features.
The new `configure --enable-local-rebuild` option specifies that we are rebuilding from the current release. The current bootstrap key is used for the local rustc, and current stage1 features are also assumed. Both the makefiles and rustbuild support this configuration.
Fixes#29556
r? @alexcrichton
Deprecate {f32,f64}::abs_sub.
The abs_sub name is misleading: the function actually computes the
positive difference (`fdim` in C), not the `(x - y).abs()` that *many* people expect
from the name.
This function can be replaced with just `(x - y).max(0.0)`, mirroring
the `abs` version, but this behaves differently with NAN: `NAN.max(0.0)
== 0.0`, while `NAN.positive_diff(0.0) == NAN`. People who absolutely
need that behaviour can use the C function directly and/or talk to the libs
team (we haven't encountered a concrete use-case for this functionality).
Closes#30315.
The previous explanation does not seem to explain what it means for an
implementation parameter to be used or unused. The new explanation lists
the three ways specific ways by which an impl parameter becomes constrained
(taken from RFC 447).
This also adds a link to RFC 447.
The explanation has two different examples. The first is adapted from RFC 447,
and shows an instance of E0207 on a impl for a type. The second one is a trait
impl example adapted from issue #22834.
Closes#33650
As some drive-by's:
* moved bitwise operators into `mod bitslice`
* factored out `fn gen` and `fn kill` methods on `BlockSets` type
* removed outdated comment about `fn propagate_call_return`
Allow `concat_idents!` in type positions as well as in expression positions
This allows the `concat_idents!` macro in type positions as well as in expression positions.
r? @nrc
Add explicit "Derivable" and "How can I implement `Default`" sections.
Copied relevant sections from the module-level documentation, but also
linked to there-- it has a more comprehensive narrative with examples
that show implementation AND use. Decided to just put implementation
example in the trait documentation.
The new order puts all the "when" questions together and puts the "how"
question with the "derivable" section. So you have to scroll past (and
hopefully read) the can/cannot/should caveats and guidelines to get to
the information about how to actually go about doing it once you've
determined that you can and should, with derivable information first so
that you can just use the derived implementation if that applies.
Previous order:
* General explanation
* When can my type be `Copy`?
* How can I implement `Copy`?
* When can my type _not_ be `Copy`?
* When should my type be `Copy`?
* Derivable
New order:
* General explanation
* When can my type be `Copy`?
* When can my type _not_ be `Copy`?
* When should my type be `Copy`?
* Derivable
* How can I implement `Copy`?
I think these just got out of sync, but both use a lexicographic
ordering.
Relevant commits in the history of these explanations:
* 8b81f76 on 2015-06-30
* e22770b on 2016-02-09
Efficient trie lookup for boolean Unicode properties
Replace binary search of ranges with trie lookup using leaves of
64-bit bitmap chunks. Benchmarks suggest this is approximately 10x
faster than the bsearch approach.
Use libc::abort, not intrinsics::abort, in rtabort!
intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.
For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.
On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.
This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!
cc #31273
cc #31333
intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.
For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.
On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.
This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!
cc #31273
cc #31333
