Change compare_exchange to return a Result<T, T>
As per the discussion in #31767
I also changed the feature name from `extended_compare_and_swap` to `compare_exchange`.
r? @alexcrichton
std: Revert addition of `into_ascii_*` methods
The addition of these methods in #31335 required adding impls of the trait for
the `String` and `Vec<T>` types. This unfortunately caused a regression (#32074)
in type inference for using these methods which the libs team has decided to not
push forward with. These methods were stabilized in #32020 which was intended to
get backported to beta, but the backport hasn't happened just yet. This commit
reverts both the addition and stabilization of these methods.
One proposed method of handling this, in #32076, was to move the methods to an
extra trait to avoid conflicts with type inference. After some discussion,
however, the libs team concluded that we probably want to reevaluate what we're
doing here, so discussion will continue on the tracking issue, #27809.
Closes#32074
Use explicit -march flags in the i586 mk file
`-march` should definitely go last, after the environment `$C(XX)FLAGS`, or it's going to remain brittle.
This should fix cross-compilation issues on x86_64 (possibly x86 too on some newer distros) - it was far too assuming of me to expect you really had to want i586 using your own flags.
Make AssertRecoverSafe's field public
It's basically the very definition of a newtype, so we might as well
make things easy on people and let them construct and access it
directly.
r? @aturon
docs: `let` introduces a statement
I changes *expression* to *statement* to make more accurate, because in Rust, `let` introduces a declaration statement.
Fix usability problem when browse document locally
You cannot use `history.replaceState` when you browse locally, it breaks the security policy of Chrome and perhaps other browsers.
Closes https://github.com/rust-lang/rust/issues/32307
Thank @crumblingstatue for the help!
syntax: impl ToTokens for P<ast::ImplItem>
I'm working on updating zinc for latest rust, and it appears that I need this impl[0].
More generally, I realise that libsyntax is "Whatever the compiler team needs to build a compiler", but should I just open a PR fleshing this out for all types?
https://github.com/hackndev/zinc/blob/master/ioreg/src/builder/setter.rs#L194-L197
Add intrinsics for float arithmetic with `fast` flag enabled
Add intrinsics for float arithmetic with `fast` flag enabled
`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe"
(according to llvm) float optimizations.
See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags
Providing these operations with less associativity rules (for example)
is useful to numerical applications.
For example, the summation loop:
let sum = 0.;
for element in data {
sum += *element;
}
Using the default floating point semantics, this loop expresses that the
floats must be added in a sequence, one after another. This constraint
is usually completely unintended, and it means that no auto-vectorization
is possible.
derive: Avoid emitting provided PartialEq, PartialOrd methods for c-like enums
derive: Avoid emitting provided PartialEq, PartialOrd method for c-like enums
`ne` is completely symmetrical with the method `eq`, and we can save
rust code size and compilation time here if we only emit one of them
when possible.
One case where it's easy to recognize is when it's a C-like enum. Most
other cases can not omit ne, because any value field may have a custom
PartialEq implementation.
`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe"
(according to llvm) float optimizations.
See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags
Providing these operations with less precise associativity rules (for
example) is useful to numerical applications.
For example, the summation loop:
let sum = 0.;
for element in data {
sum += *element;
}
Using the default floating point semantics, this loop expresses the
floats must be added in a sequence, one after another. This constraint
is usually completely unintended, and it means that no autovectorization
is possible.
Adjustments to the panic hook API
Rename `set_handler` and `take_handler` to `set_hook` and `take_hook` since we're not actually "handling" (i.e. fixing) anything.
Also alter `set_hook` to take a `Box<Fn(&PanicInfo) + 'static + Sync + Send>` rather than a parameterized closure since there's otherwise no easy way to re-register a hook that came from `take_hook`.
cc #30449
r? @aturon
Refactor call & function handling in trans, enable MIR bootstrap.
Non-Rust and Rust ABIs were combined into a common codepath, which means:
* The ugly `__rust_abi` "clown shoes" shim for C->Rust FFI is gone, fixes#10116.
* Methods, *including virtual ones* support non-Rust ABIs, closes#30235.
* Non-Rust ABIs also pass fat pointers in two arguments; the result should be identical.
* Zero-sized types are never passed as arguments; again, behavior shouldn't change.
Additionally, MIR support for calling intrinsics (through old trans) was implemented.
Alongside assorted fixes, it enabled MIR to launch 🚀 and do a *complete* bootstrap.
To try it yourself, `./configure --enable-orbit` *or* `make RUSTFLAGS="-Z orbit"`.
Expose the key of Entry variants for HashMap and BTreeMap.
This PR addresses [issue 1541](https://github.com/rust-lang/rfcs/issues/1541) by exposing the key of `HashMap` and `BTreeMap` entry variants. Basic tests are provided.
Add is_documentation for IPv6
This function returns true if the given IPv6 is reserved for
documentation. Also, reject this block in the is_global check
