This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as
opposed to the 2 that our builders currently have. Should help make those OSX
builds a bit speedier!
Fix save-analysis generation crash with invalid tuple access
Reproduction:
```rust
fn invalid_tuple_struct_accessing() {
bar.0;
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> test.rs:2:5
|
2 | bar.0;
| ^^^ not found in this scope
error[E0601]: main function not found
error: internal compiler error: librustc_save_analysis/dump_visitor.rs:1678: Expected struct or tuple type, found TyError
--> test.rs:2:5
|
2 | bar.0;
| ^^^^^
thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:482:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
This should fix a crash in RLS when editing such code. cc @nrc
Stabilize FusedIterator
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Closes#35602
Also move the check for not having type parameters into ast_validation.
I was not sure what to do with compile-fail/issue-23046.rs: The issue looks like
maybe the bounds actually played a role in triggering the ICE, but that seems
unlikely given that the compiler seems to entirely ignore them. However, I
couldn't find a testcase without the bounds, so I figured the best I could do is
to just remove the bounds and make sure at least that keeps working.
Add functions for reversing the bit pattern in an integer
I'm reviving PR #32798 now that the LLVM issues have been resolved.
> This adds the bitreverse intrinsic and adds a reverse_bits function to all integer types.
Suggest type for overflowing bin/hex-literals
Fixes#48073
For hexadecimal and binary literals, which overflow, it gives an additional note to the warning message, like in this [comment](https://github.com/rust-lang/rust/issues/48073#issuecomment-365370113).
Additionally it will suggest a type (`X < Y`):
- `iX`: if literal fits in `uX` => `uX`, else => `iY`
- `-iX` => `iY`
- `uX` => `uY`
Exceptions: `isize`, `usize`. I don't think you can make a good suggestion here. The programmer has to figure it out on it's own in this case.
r? @oli-obk
The ExplicitSelf::determine function expects to be able to compare regions.
However, when the compare_self_type error reporting code runs we haven't
resolved bound regions yet. Thus we replace them with free regions first.
Have Vec use slice's implementations of Index<I> and IndexMut<I>
This PR simplifies the implementation of Index and IndexMut on Vec, and in the process enables indexing Vec by any user types that implement SliceIndex.
The stability annotations probably need to be changed, but I wasn't sure of the right way to do that. It also wasn't completely clear to me if this change could break any existing code.
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Currently rustc isn't always the best at producing deterministic builds of a
crate when the source directory of a crate is changed. This is happening due to
what appears two different sources:
* First the `-L` paths passed to rustc are hashed into the crate hash. These
paths through Cargo are typically absolute paths that can vary if the build
directory changes.
* Next the paths passed to `--extern` are also hashed which like `-L` can change
if the build directory changes.
This commit fixes these two sources of nondeterminism by ensuring that avoiding
tracking the hashes of these arguments on the command line. For `-L` paths
they're either related to loading crates (whose hashes are tracked elsewhere) or
native librarise used in the linking phase (which isn't incremental). The
`--extern` paths are similar in that they're related to crate resolution which
is already tracked independently of the command line arguments.
Closes#48019
