Be more obvious when suggesting dereference
Include `&` span when suggesting dereference on a span that is already a reference:
```
error: non-reference pattern used to match a reference (see issue #42640)
--> dont-suggest-dereference-on-arg.rs:16:19
|
16 | .filter(|&(ref a, _)| foo(a))
| ^^^^^^^^^^^ help: consider using: `&&(ref k, _)`
|
= help: add #![feature(match_default_bindings)] to the crate attributes to enable
```
Fix#45925.
rustc: Add support for some more x86 SIMD ops
This commit adds compiler support for two basic operations needed for binding
SIMD on x86 platforms:
* First, a `nontemporal_store` intrinsic was added for the `_mm_stream_ps`, seen
in rust-lang-nursery/stdsimd#114. This was relatively straightforward and is
quite similar to the volatile store intrinsic.
* Next, and much more intrusively, a new type to the backend was added. The
`x86_mmx` type is used in LLVM for a 64-bit vector register and is used in
various intrinsics like `_mm_abs_pi8` as seen in rust-lang-nursery/stdsimd#74.
This new type was added as a new layout option as well as having support added
to the trans backend. The type is enabled with the `#[repr(x86_mmx)]`
attribute which is intended to just be an implementation detail of SIMD in
Rust.
I'm not 100% certain about how the `x86_mmx` type was added, so any extra eyes
or thoughts on that would be greatly appreciated!
This commit adds compiler support for two basic operations needed for binding
SIMD on x86 platforms:
* First, a `nontemporal_store` intrinsic was added for the `_mm_stream_ps`, seen
in rust-lang-nursery/stdsimd#114. This was relatively straightforward and is
quite similar to the volatile store intrinsic.
* Next, and much more intrusively, a new type to the backend was added. The
`x86_mmx` type is used in LLVM for a 64-bit vector register and is used in
various intrinsics like `_mm_abs_pi8` as seen in rust-lang-nursery/stdsimd#74.
This new type was added as a new layout option as well as having support added
to the trans backend. The type is enabled with the `#[repr(x86_mmx)]`
attribute which is intended to just be an implementation detail of SIMD in
Rust.
I'm not 100% certain about how the `x86_mmx` type was added, so any extra eyes
or thoughts on that would be greatly appreciated!
rustbuild: Enable WebAssembly backend by default
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
rustc: don't mark lifetimes as early-bound in the presence of impl Trait.
This hack from the original implementation shouldn't be needed anymore, thanks to @cramertj.
r? @nikomatsakis
Properly handle reexport of foreign items.
Handles `pub use` of `extern { fn, static, type }`. Also plug in some more `match` arms where handling `extern type` is reasonable.
Fixed#46098.
rustbuild: Update LLVM and enable ThinLTO
This commit updates LLVM to fix#45511 (https://reviews.llvm.org/D39981) and
also reenables ThinLTO for libtest now that we shouldn't hit #45768. This also
opportunistically enables ThinLTO for libstd which was previously blocked
(#45661) on test failures related to debuginfo with a presumed cause of #45511.
Closes#45511
Turns out ThinLTO was internalizing this symbol and eliminating it. Worse yet if
you compiled with LTO turns out no TLS destructors would run on Windows! The
`#[used]` annotation should be a more bulletproof implementation (in the face of
LTO) of preserving this symbol all the way through in LLVM and ensuring it makes
it all the way to the linker which will take care of it.
incr.comp.: Make sure we don't lose unused green results from the query cache.
In its current implementation, the query result cache works by bulk-writing the results of all cacheable queries into a monolithic binary file on disk. Prior to this PR, we would potentially lose query results during this process because only results that had already been loaded into memory were serialized. In contrast, results that were not needed during the given compilation session were not serialized again.
This PR will do one pass over all green `DepNodes` that represent a cacheable query and execute the corresponding query in order to make sure that the query result gets loaded into memory before cache serialization.
In the future we might want to look into a serialization format the can be updated in-place so that we don't have to load unchanged results just for immediately storing them again.
r? @nikomatsakis
Include enclosing span when suggesting dereference on a span that is
already a reference:
```
error: non-reference pattern used to match a reference (see issue #42640)
--> dont-suggest-dereference-on-arg.rs:16:19
|
16 | .filter(|&(ref a, _)| foo(a))
| ^^^^^^^^^^^ help: consider using: `&&(ref k, _)`
|
= help: add #![feature(match_default_bindings)] to the crate attributes to enable
```
Add a MIR pass to lower 128-bit operators to lang item calls
Runs only with `-Z lower_128bit_ops` since it's not hooked into targets yet.
This isn't really useful on its own, but the declarations for the lang items need to be in the compiler before compiler-builtins can be updated to define them, so this is part 1 of at least 3.
cc https://github.com/rust-lang/rust/issues/45676 @est31 @nagisa
This commit updates LLVM to fix#45511 (https://reviews.llvm.org/D39981) and
also reenables ThinLTO for libtest now that we shouldn't hit #45768. This also
opportunistically enables ThinLTO for libstd which was previously blocked
(#45661) on test failures related to debuginfo with a presumed cause of #45511.
Closes#45511
Check //~ERROR comments in ui tests
r? @nikomatsakis
cc #44844 @Phlosioneer @estebank @petrochenkov
this depends on https://github.com/rust-lang/rust/pull/46052 getting merged first (the commits are included in here)
The relevant changes of this PR are c2f0af7 and 979269b
Add hints for the case of confusing enum with its variants
A solution for https://github.com/rust-lang/rust/issues/43871. When one uses an enum in a place that accepts variants (e.g., `Option(result)` instead of `Some(result)`), suggest one of this enum's variants.
cc @estebank
The current implementation/documentation was made to avoid sNaN because of
potential safety issues implied by old/bad LLVM documentation. These issues
aren't real, so we can just make the implementation transmute (as permitted
by the existing documentation of this method).
Also the documentation didn't actually match the behaviour: it said we may
change sNaNs, but in fact we canonicalized *all* NaNs.
Also an example in the documentation was wrong: it said we *always* change
sNaNs, when the documentation was explicitly written to indicate it was
implementation-defined.
This makes to_bits and from_bits perfectly roundtrip cross-platform, except
for one caveat: although the 2008 edition of IEEE-754 specifies how to
interpet the signaling bit, earlier editions didn't. This lead to some platforms
picking the opposite interpretation, so all signaling NaNs on x86/ARM are quiet
on MIPS, and vice-versa.
NaN-boxing is a fairly important optimization, while we don't even guarantee
that float operations properly preserve signalingness. As such, this seems like
the more natural strategy to take (as opposed to trying to mangle the signaling
bit on a per-platform basis).
This implementation is also, of course, faster.
Rename param in `[T]::swap_with_slice` from `src` to `other`.
The idea of ‘source’ and ‘destination’ aren’t very applicable for this
operation since both slices can both be considered sources and
destinations.
Add test for #44953
Added the requested test - trying to see if it passes; my local build fails, but not sure why - the nightly shows this output, but in my build the compilation error changed.
Fixes#44953.
Add Box::leak<'a>(Box<T>) -> &'a mut T where T: 'a
Adds:
```rust
impl<T: ?Sized> Box<T> {
pub fn leak<'a>(b: Box<T>) -> &'a mut T where T: 'a {
unsafe { &mut *Box::into_raw(b) }
}
}
```
which is useful for when you just want to put some stuff on the heap and then have a reference to it for the remainder of the program.
r? @sfackler
cc @durka
typeck aggregate rvalues in MIR type checker
This branch is an attempt to land content by @spastorino and @Nashenas88 that was initially landed on nll-master while we waited for https://github.com/rust-lang/rust/pull/45825 to land.
The biggest change it contains is that it extends the MIR type-checker to also type-check MIR aggregate rvalues (at least partially). Specifically, it checks that the operands provided for each field have the right type.
It does not yet check that their well-formedness predicates are met. That is https://github.com/rust-lang/rust/issues/45827. It also does not check other kinds of rvalues (that is https://github.com/rust-lang/rust/issues/45959). @spastorino is working on those issues now.
r? @arielb1
Implement in-band lifetime bindings
TODO (perhaps in a future PR): Should we ban explicit instantiation of generics with in-band lifetimes, or is it uncontroversial to just append them to the end of the lifetimes list?
Fixes#46042, cc #44524.
r? @nikomatsakis
Use the proper term when using non-existing variant
When using a non-existing variant, function or associated item, refer to
the proper term, instead of defaulting to "associated item" in
diagnostics.
Fix#28972.
```
error[E0599]: no variant named `Quux` found for type `Foo` in the current scope
--> file.rs:7:9
|
7 | Foo::Quux(..) =>(),
| ^^^^^^^^^^^^^
```
Allow filtering analysis by reachability
Fixes#43521.
Fixes https://github.com/nrc/rls-analysis/issues/79.
This PR allows a user to filter items present in the save-analysis data by setting the `reachable_only` config option. This option is intended for use by the new rustdoc. The PR isn't quite finished, because it's dependent on a new release of rls-data, but I want to make sure that the approach is valid.
https://github.com/nrc/rls-analysis/issues/79 mentions that `pub use` might need to be handled, but my thinking is that the consumer of the analysis data would be able to infer which imports are `pub use`, and which items are only reachable through `pub use`, so that doesn't need to be handled here.
r? @nrc
