Made the 'good' example compile.
I got to the E0368 error page by following the link in the output of the
compiler. My understanding is that the first example is 'bad' and the
second one is 'good'. Following that logic, I pasted the second example
into the file and to my surprise it did not compile. This commit fixes
the example to make it paste-able.
Alter E0412 help message wording
The initial wording does not make sense due to an extra 'to'.
There are two potential candidates we can change this to:
- 'you can import it into scope'
- 'to import it into scope'
In keeping the changes minimal, we choose the first, as this is more in line with the grammar of the extended candidates help message.
The initial wording does not make sense due to an extra 'to'.
There are two potential candidates we can change this to:
- 'you can import it into scope'
- 'to import it into scope'
In keeping the changes minimal, we choose the first, as this is more in line with the grammar of the extended candidates help message.
Fix floating point fast-math intrinsics
The implementation did not handle the case where both operands were constants, which caused an llvm assertion:
```
rustc: //buildslave//rust-buildbot//slave//nightly-dist-rustc-musl-linux//build//src//llvm//include/llvm/Support/Casting.h:237:
typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Instruction*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
```
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
Fixes issue #29124.
If method is called on a function type a note is generated to suggest
that the developer may have forgotten to call it.
e.g.
fn main() {
let mut guess = String::new();
std::io::stdin.read_line(&mut guess);
}
will generate the note:
note: called method on function type. did you mean `std::io::stdin().read_line(..)`?
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.
The older code would sometimes swallow errors or fail to produce a
suggestion. The newer code does not. However, just printing everything
would produce a bunch of new and kind of annoying errors, so continue
to swallow `T: 'a` errors so long as there are other things to show.
