Prohibit `global_allocator` in submodules
Background: #44113 is caused by weird interactions with hygiene. Hygiene is hard. After a lot of playing around, we decided that the best path forward would be to prohibit `global_allocator`s from being in submodules for now. When somebody gets it working, we can re-enable it.
This PR contains the following
- Some hygiene "fixes" -- things I suspect are the correct thing to do that will make life easier in the future. This includes using call_site hygiene for the generated module and passing the correct crate name to the expansion config.
- Comments and minor formatting fixes
- Some debugging code
- Code to prohibit `global_allocator` in submodules
- Test checking that the proper error occurs.
cc #44113#49320#51241
r? @alexcrichton
- we need to figure out hygiene first
- change the test to check that the prohibition works with a good error
msg
- leaves some comments and debugging code
- leaves some of our supposed fixes
Update rustfmt submodule
The version of rustfmt currently shipped with nightly breaks code that uses `break 'label`. This PR updates the submodule to include the fix (https://github.com/rust-lang-nursery/rustfmt/pull/2774).
Option::get_or_insert(_with): Replace unreachable! with unreachable_unchecked
Optimize codegen for both functions as the None branch is trivially not reachable.
Rename hir::ExprAgain to hir::ExprContinue
The current name is confusing and historical.
I also used this PR to clean up the annoying indentation in `check/mod.rs`. If that's viewed as too tangential a change, I'll split it up, but it seemed reasonable to slip it in to reduce @bors's work. It's easy to compare for the two commits individually.
r? @petrochenkov
async/await
This PR implements `async`/`await` syntax for `async fn` in Rust 2015 and `async` closures and `async` blocks in Rust 2018 (tracking issue: https://github.com/rust-lang/rust/issues/50547). Limitations: non-`move` async closures with arguments are currently not supported, nor are `async fn` with multiple different input lifetimes. These limitations are not fundamental and will be removed in the future, however I'd like to go ahead and get this PR merged so we can start experimenting with this in combination with futures 0.3.
Based on https://github.com/rust-lang/rust/pull/51414.
cc @petrochenkov for parsing changes.
r? @eddyb
Add label to lint for lifetimes used once
```
error: lifetime parameter `'a` only used once
--> $DIR/fn-types.rs:19:10
|
LL | a: for<'a> fn(&'a u32), //~ ERROR `'a` only used once
| ^^ -- ...is used only here
| |
| this lifetime...
```
Support future deprecation for rustc_deprecated
Follow-up to #49179 to allow `since` parameters to be set to future versions of Rust and correspondingly to not be treated as deprecated until that version. This is required for #30459 to be completed (though we'll need to wait until this hits beta).
Rollup of 6 pull requests
Successful merges:
- #51158 (Mention spec and indented blocks in doctest docs)
- #51629 (Do not consume semicolon twice while parsing local statement)
- #51637 (Update zx_cprng_draw_new on Fuchsia)
- #51664 (make more libsyntax methods public)
- #51666 (Disable probestack when GCOV profiling is being used)
- #51703 (Recognize the extra "LLVM tools versions" argument to build-manifest.)
Failed merges:
r? @ghost
