Remove documentation about proc_macro being bare-bones
A large chunk of useful API surface area is stabilizing in Rust 1.29. We no longer have a commitment to expand the API over time as much as implied by these comments.
r? @alexcrichton
docs: Use dollar sign for all bash prompts
Making it consistent across the board, as most of them already use `$`.
Also split one continues bash run into two, to make it easier see
different runs: one with warning and another with error.
Stabilization change for mod.rs
This change is in response to https://github.com/rust-lang/rust/issues/53125.
The patch makes the feature accepted and removes the tests that tested the
non-accepted status of the feature.
Update documentation for fill_buf in std::io::BufRead
Brings the documentation in line with the BufReader implementation.
Fixes#48022.
This is my first PR, and I think the `E-easy` label is very cool, as so is the practice of describing the fix but leaving it for someone else; it really makes it a lot less intimidating to get started with something!
A few cleanups and minor improvements to rustc_passes
- prefer `if let` to `match` when only one branch matters
- prefer equality checks to pattern matching
- prefer `is_empty` to `len() == 0`
- collapse a couple of `if` expressions
- rename `label` to `destination` when destructuring `hir::ExprKind::Continue`
- `derive Copy` for `Promotability`
- `impl BitAndAssign` for `Promotability`
- a few formatting fixes
- a few other minor cleanups
Fix a few AMDGPU related issues
* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
support ascription for patterns in NLL
This implements the strategy outlined in [this comment](https://github.com/rust-lang/rust/issues/47184#issuecomment-416669986):
- We first extend the NLL subtyping code so it can handle inference variables and subtyping.
- Then we extend HAIR patterns with type ascription.
- Then we treat the type `T` in `let pat: T = ...` as an ascription.
Before landing, a few things:
- [x] Fix the WF rule bug (filed a FIXME https://github.com/rust-lang/rust/issues/54105)
- [x] Fix an ICE I encountered locally around bound regions, or else file a follow-up
- [x] More tests probably =)
r? @pnkfelix
stabilize #[used]
closes#40289
RFC for stabilization: rust-lang/rfcs#2386
r? @Centril
Where should this be documented? Currently the documentation is in the unstable book
Invocation/expansion ID (aka `Mark`) is not really necessary for resolving a macro path.
What is really necessary is its parent module, parent expansion and parent legacy scope.
This is required for validation resolutions of built-in attributes, which don't get their own `Mark`s
Allow named lifetimes in async functions.
- Fixes#53174
Code by @eddyb; @cramertj suggested I lift it off another change so we can fix#53174.
r? @cramertj
For some weird reason this fixes `intrinsic-move-val`. It also affects
various test heuristics. I removed one test (`reborrow_basic`) that
didn't seem to really be testing anything in particular anymore,
compared to all the other tests we've got.
rustc_resolve: inject `uniform_paths` canaries regardless of the feature-gate, on Rust 2018.
This PR is an attempt at future-proofing "anchored paths" by emitting the same ambiguity errors that `#![feature(uniform_paths)]` would, with slightly changed phrasing (see added UI tests).
Also, on top of #54005, this PR allows this as well:
```rust
use crate_name;
use crate_name::foo;
```
In that any ambiguity between an extern crate and an import *of that same crate* is ignored.
r? @petrochenkov cc @aturon @Centril @joshtriplett
#53359: putting multiple unresolved import on single line
r? @estebank
Here is WIP implementation of #53359
this PR have clubbed multiple unresolved imports into a single line.
I think still two things need to improve like giving specific `label message` for each span of multi_span(how we can do this?) and second we are getting a warning while compiling, stating something like `E0432` have been passed before.
