Fix#35829 (`quote!()` does not handle `br#"…"#`)
Fix issue #35829 (syntax extension's `quote_expr!()` does not handle `b"…"` and proc_macro's `quote!()` does not handle `r#"…"#`)
* Handles `b"…"`, `br#"…"#` and `...` for `quote_expr!()`.
* Refactored the match statement to allow it to complain loudly on any unhandled token.
* Similarly, proc_macro's `quote!()` did not handle `br#"…"#` or `r#"…"#`, so this PR fixes it too.
* #42007 happens because the Session LintStore is emptied when linting.
* The Session LintStore is emptied because the checker (Early/LateContext)
wants ownership.
* The checker wants ownership because it wants to mutate the pass objects
and lint levels.
The ownership of the whole store is not essential, only the lint levels and
pass objects need to be owned. Therefore, these parts are extracted out of
the LintStore into a separate structure `LintSession`. The "check crates"
methods can operate on `&mut LintSession` instead of `&mut LintStore`.
This is a minor BREAKING CHANGE for lint writers since the `LintContext`
trait is changed: the `mut_lints` and `level_stack` methods are removed.
But no one outside of `librustc/lint/context.rs` is using these functions,
so it should be safe.
Document the `proc_macro` feature in the Unstable Book
Discusses the `proc_macro` feature flag and the features it enables:
* Implicit enable of `extern_use_macros` feature and how to import proc macros
* Error handling in proc macros (using panic messages)
* Function-like proc macros using `#[proc_macro]` and a usage example for creating and invoking
* Attribute-like proc macros using `#[proc_macro_attribute]` and a usage example for creating and invoking
[Rendered](https://github.com/abonander/rust/blob/book_proc_macro/src/doc/unstable-book/src/language-features/proc-macro.md)
Update cargo submodule
This pulls in a fix for #41797 to the master branch, I'll send a separate PR for
the beta branch. Note that the Cargo PR in question to pull in is https://github.com/rust-lang/cargo/pull/4046
avoid cycles in mir-dump, take 2
This fixes#41697, for real this time, but I'm not sure how best to add a regression test. I was considering maybe adding some flag so that the MIR dumping doesn't actually get written to files (e.g., overloading the directory flag so you can specify nil or something).
cc @dwrensha @oli-obk
use equality in the coerce-unsized check
This seems both to be a safe, conservative choice, and it sidesteps the cycle in #41849. Note that, before I converted variance into proper queries, we were using a hybrid of subtyping and equality, due to the presence of a flag that forced invariance if variance had not yet been computed. (Also, Coerce Unsized is unstable.)
Fixes#41936.
r? @eddyb
Add lint for unused macros
Addresses parts of #34938, to add a lint for unused macros.
We now output warnings by default when we encounter a macro that we didn't use for expansion.
Issues to be resolved before this PR is ready for merge:
- [x] fix the NodeId issue described above
- [x] remove all unused macros from rustc and the libraries or set `#[allow(unused_macros)]` next to them if they should be kept for some reason. This is needed for successful boostrap and bors to accept the PR. -> #41934
- [x] ~~implement the full extent of #34938, that means the macro match arm checking as well.~~ *let's not do this for now*
This is a resurrection of #40776, combining their Windows setup with an
additional setup on Unix to set the program group's niceness to +10
(low-but-not-lowest priority) when the `low_priority` option is on.
rustdoc: Display `extern "C" fn` instead of `extern fn`
It was decided in rust-lang-nursery/fmt-rfcs#52 to be explicit about the ABI so rustdoc should follow suit.
[Doc] Add links to the `thread::LocalKey` doc.
Part of #29378 .
I do not know exactly what should be done for the `cleanup` part, if you have any idea I'll gladly do it.
r? @rust-lang/docs
[Doc] Implrove `thread::Builder`'s doc.
Part of #29378 .
- Explains *why* we would use the builder instead ofthe free function.
- Changes the parent-child explanation for a spawned-caller in `thread::Builder::spawn`
- Adds a link to `io::Result` in `thread::Builder`
- Corrects the return type doc in `thread::Builder::spawn`
r? @rust-lang/docs
Make unsatisfied trait bounds note multiline
Make diagnostic note for existing method with unsatisfied trait bounds
multiline for cleaner output.
```
= note: the method `count` exists but the following trait bounds were not satisfied:
`[closure@../../src/test/compile-fail/issue-36053-2.rs:17:39: 17:53] : std::ops::FnMut<(&_,)>`
`std::iter::Filter<std::iter::Fuse<std::iter::Once<&str>> [closure@../../src/test/compile-fail/issue-36053-2.rs:17:39: 17:53]> : std::iter::Iterator`
```
Before:
```
= note: the method `count` exists but the following trait bounds were not satisfied: `[closure@../../src/test/compile-fail/issue-36053-2.rs:17:39: 17:53] : std::ops::FnMut<(&_,)>`, `std::iter::Filter<std::iter::Fuse<std::iter::Once<&str>>, [closure@../../src/test/compile-fail/issue-36053-2.rs:17:39: 17:53]> : std::iter::Iterator`
```
Make only rustc_trans depend on rustc_llvm
With these changes, only rustc_trans depends directly on rustc_llvm (and no crate gained a new dependency on trans). This means changing LLVM doesn't rebuild librustc or rustc_metadata, only rustc_trans, rustc_driver and the rustc executable
Also, rustc_driver technically doesn't know about LLVM any more (of course, it still handles a ton of options that conceptually refer to LLVM, but it delegates their implementation to trans).
What I *didn't* implement was merging most or all of rustc_llvm into rustc_trans. I ran into a nasty bug, which was probably just a silly typo somewhere but I probably won't have the time to figure it out in the next week or two. I opened #41699 for that step.
Fixes#41473
