```
error[E0282]: type annotations needed in `std::result::Result<i32, E>`
--> file7.rs:3:13
|
3 | let b = Ok(4);
| - ^^ cannot infer type for `E` in `std::result::Result<i32, E>`
| |
| consider giving `b` a type`
```
When encountering code where type inference fails, add more actionable
information:
```
fn main() {
let foo = Vec::new();
}
```
```
error[E0282]: type annotations needed for `std::vec::Vec<_>`
--> $DIR/vector-no-ann.rs:2:16
|
LL | let foo = Vec::new();
| --- ^^^^^^^^ cannot infer type for `T`
| |
| consider giving `foo` the type `std::vec::Vec<_>` with the type parameter `T` specified
```
We still need to modify type printing to optionally accept a
`TypeVariableTable` in order to properly print `std::vec::Vec<T>`.
CC #25633.
Update musl-cross-make to 0.9.8
This version uses musl 1.1.22 and GCC 6.4.0 by default. It also
contains support for newer binutils and GCC versions, should we
want to bump those as well. But I'm purposefully limiting this
patch in order to reduce the surface area for controversy.
Introduce Rust symbol mangling scheme.
This is an implementation of a "feature-complete" Rust mangling scheme, in the vein of rust-lang/rfcs#2603 ~~- but with some differences, see https://github.com/rust-lang/rfcs/pull/2603#issuecomment-458410463 for details~~ (@michaelwoerister integrated my proposed changes into the RFC itself).
On nightly, you can now control the mangling scheme with `-Z symbol-mangling-version`, which can be:
* `legacy`: the older mangling version, still the default currently
* `v0`: the new RFC mangling version, as implemented by this PR
To test the new mangling, set `RUSTFLAGS=-Zsymbol-mangling-version=v0` (or change [`rustflags` in `.cargo/config.toml`](https://doc.rust-lang.org/cargo/reference/config.html#configuration-keys)). Please note that only symbols from crates built with that flag will use the new mangling, and that tool support (e.g. debuggers) will be limited initially, and it may take a while for everything to be upstreamed. However, `RUST_BACKTRACE` should work out of the box with either mangling version.
<hr/>
The demangling implementation PR is https://github.com/alexcrichton/rustc-demangle/pull/23
~~(this PR already uses it via a git dependency, to allow testing)~~.
Discussion of the *design* of the mangling scheme should still happen on the RFC, but this PR's specific implementation details can be reviewed in parallel.
*Notes for reviewers*:
* ~~only the last 6 commits are specific to this branch, if necessary I can open a separate PR for everything else (it was meant to be its own small refactoring, but it got a bit out of hand)~~
~~based on #58140~~
* the "harness" commit is only there because it does some extra validation (comparing the demangling from `rustc-demangle` to the compiler's pretty-printing, adjusted slightly to produce the same output), that I would like to try on crater
* ~~there is the question of whether we should turn on the new mangling now, wait for tools to support it (I'm working on that), and/or have it under a `-Z` flag for now~~ (we're gating this on `-Z symbol-mangling-version=v0`, see above)
r? @nikomatsakis / @michaelwoerister cc @rust-lang/compiler
Migrate some books to mdbook version 0.2
There are 3 books still using old version but they need more effort so I hope to do them in subsequent PR if I find the time.
Swap order of `unsafe async fn` to `async unsafe fn`
Change the order of `unsafe async fn` to `async unsafe fn`.
I had intended to do this a while back but didn't get around to it...
This should be done because:
- It is the order used by `const unsafe fn` so therefore it is consistent.
- This keeps all the "effect/restriction" modifiers to the left of `unsafe` (which according to some is not an effect) instead of mixing them such that we are more forward compatible with some sort of effect system.
r? @cramertj
Speed up Azure CI installing Windows dependencies
There is known issue where PowerShell is unreasonably slow downloading
files due to an issue with rendering the progress bar, see this [issue](https://github.com/PowerShell/PowerShell/issues/2138)
That issue is fixed in PowerShell Core (available in Azure Pipelines as
pwsh.exe) but it can also be worked around by setting:
$ProgressPreference = 'SilentlyContinue'
I measured downloading LLVM and it took about 220s before, 5s after, so the improvement is significant.
error: remove StringError from Debug output
Seeing `StringError("something something")` in debug output can cause
someone to think there was an error dealing with `String`s, not that the
error type is just a string. So, remove that noise.
For example:
```
io error: Custom { kind: InvalidData, error: StringError("corrupt data") }
```
With this change:
```
io error: Custom { kind: InvalidData, error: "corrupt data" }
```
Make the `type_name` intrinsic deterministic
cc @eddyb for the printing infrastructure
cc @Centril for the deterministic (coherent?) output
r? @sfackler
ci: Favor SCRIPT instead of RUST_CHECK_TARGET
Since #61212 we've been timing out on OSX, and this looks to be because
we're building tools like Cargo and the RLS twice instead of once. This
turns out to be a slight bug in our configuration. CI builders using the
`RUST_CHECK_TARGET` directive actually execute `make all` just before
their acual target. In `make all` we're building a stage2 cargo, and
then in `make dist` we're building a stage1 cargo.
Other builders use `SCRIPT` which provides explicit control over what
`x.py` script, for example, is used to execute the build. This moves
almost all targets to using `SCRIPT` to ensure that we're explicitly
specifying what's being built where. Additionally this updates the logic
of `RUST_CHECK_TARGET` to remove the pre-flight tidy as well as the
pre-flight `make all`. The system LLVM builder (run on PRs) now
explicitly runs tidy first and then runs the rest of the test suite.
