Split and expand nonstandard-style lints unicode unit test.
RFC 2457 requested that the `nonstandard_style` series of linted be adjusted to cover the non_ascii_identifier case. However when i read the code of those implementations, it seems they're already supporting non_ascii_identifiers. But the exact rules is a little different than what's proposed in RFC 2457.
So I splitted and expanded the existing test case to try to exercise every branch in the code. I think it'll also be easier to examine the cases in these unit tests to see whether it's ok to just leave them as is, or some adjustments are needed.
r? @Manishearth
Recover extra trailing angle brackets in struct definition
This commit applies the existing 'extra angle bracket recovery' logic
when parsing fields in struct definitions. This allows us to continue
parsing the struct's fields, avoiding spurious 'missing field' errors in
code that tries to use the struct.
Handle `macro_rules!` tokens consistently across crates
When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition.
This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case.
To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from.
This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group.
See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
Provide more information on duplicate lang item error.
This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing, and this might help in diagnosing what has happened.
Here's an example when hitting a bug with Cargo's build-std:
```
error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`.
|
= note: the lang item is first defined in crate `core` (which `z10` depends on)
= note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta
= note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta
```
expand: Stop using nonterminals for passing tokens to attribute and derive macros
Make one more step towards fully token-based expansion and fix issues described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791.
Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later.
The cost is making pretty-printing of token streams less pretty.
Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway.
Unfortunately, this is not exactly the same thing as https://github.com/rust-lang/rust/pull/73102.
One more observable effect is how `$crate` is printed in the attribute input.
Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see https://github.com/rust-lang/rust/pull/62393 and related PRs).
This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed.
So, I think we should do this regardless, but we need to run crater first.
r? @Aaron1011
When a `macro_rules!` macro expands to another `macro_rules!` macro, we
may see `None`-delimited groups in odd places when another crate
deserializes the 'inner' macro. This commit 'unwraps' an outer
`None`-delimited group to avoid breaking existing code.
See https://github.com/rust-lang/rust/pull/73569#issuecomment-650860457
for more details.
The proper fix is to handle `None`-delimited groups systematically
throughout the parser, but that will require significant work. In the
meantime, this hack lets us fix important hygiene bugs in macros
Fix wording for anonymous parameter name help
```
--> exercises/functions/functions2.rs:8:15
|
8 | fn call_me(num) {
| ^ expected one of `:`, `@`, or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a `self` type, give it a parameter name
|
8 | fn call_me(self: num) {
| ^^^^^^^^^
help: if this was a parameter name, give it a type
|
8 | fn call_me(num: TypeName) {
| ^^^^^^^^^^^^^
help: if this is a type, explicitly ignore the parameter name
|
8 | fn call_me(_: num) {
|
```
This commit changes "if this was a parameter name" to "if this is a parameter name" to match the wording of similar errors.
Use an 'approximate' universal upper bound when reporting region errors
Fixes#67765
When reporting errors during MIR region inference, we sometimes use
`universal_upper_bound` to obtain a named universal region that we
can display to the user. However, this is not always possible - in a
case like `fn foo<'a, 'b>() { .. }`, the only upper bound for a region
containing `'a` and `'b` is `'static`. When displaying diagnostics, it's
usually better to display *some* named region (even if there are
multiple involved) rather than fall back to a generic error involving
`'static`.
This commit adds a new `approx_universal_upper_bound` method, which
uses the lowest-numbered universal region if the only alternative is to
return `'static`.
Added detailed error code explanation for issue E0687 in Rust compiler.
Added proper error explanation for issue E0687 in the Rust compiler.
Error Code E0687
Sub Part of Issue #61137
r? @GuillaumeGomez
The number of symbols we allocate (even early on) seems to be platform
dependent. We only care about hygiene for the purposes of this test,
so just set all of the symbol ids to zero
Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.
However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.
This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.
Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.
The recursive check of `try_print_visible_def_path` did not properly handle
the Rust 2018 case of crate-paths without 'extern crate'. Instead, it returned
a "not found" via (false, self).
This fixes issue #56175.
added regions with counter expressions and counters.
Added codegen_llvm/coverageinfo mod for upcoming coverage map
Move coverage region collection to CodegenCx finalization
Moved from `query coverageinfo` (renamed from `query coverage_data`),
as discussed in the PR at:
https://github.com/rust-lang/rust/pull/73684#issuecomment-649882503
Address merge conflict in MIR instrument_coverage test
The MIR test output format changed for int types.
moved debug messages out of block.rs
This makes the block.rs calls to add coverage mapping data to the
CodegenCx much more concise and readable.
move coverage intrinsic handling into llvm impl
I realized that having half of the coverage intrinsic handling in
`rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any
non-llvm backend would be bound to the same decisions about how the
coverage-related MIR terminators should be handled.
To fix this, I moved the non-codegen portion of coverage intrinsic
handling into its own trait, and implemented it in `rustc_codegen_llvm`
alongside `codegen_intrinsic_call`.
I also added the (required?) stubs for the new intrinsics to
`IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do
not fail if called with these new but known intrinsics.
address PR Feedback on 28 June 2020 2:48pm PDT
Stabilize `#![feature(const_if_match)]`
Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045):
> `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following:
>
> - The initializer of a `const`, `static`, `static mut` or enum discriminant.
> - The body of a `const fn`.
> - The value of a const generic (nightly only).
> - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`).
>
> Furthermore, the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result, `let` bindings can be used alongside short-circuiting logic in those initializers.
Resolves#49146.
Ideally, we would resolve 🐳#66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative `const fn`.
r? @oli-obk
Rename clashing_extern_decl to clashing_extern_declarations.
Rename clashing_extern_decl to clashing_extern_declarations to bring in-line with lint naming conventions.
Fixes#73802.
r? @petrochenkov
Make liveness more precise for assignments to fields
Previously, we were too conservative and `x.field = 4` was treated as a "use" of `x`. Now it neither kills `x` (since other fields of `x` may still be live) nor marks it as live.
cc @jonas-schievink, who ran into this problem.
errors: use `-Z terminal-width` in JSON emitter
This PR makes the JSON emitter use `-Z terminal-width` in the "rendered" field of the JSON output.
r? @estebank
Explain move errors that occur due to method calls involving `self` (take two)
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
Adds a clearer message for when the async keyword is missing from a f…
…unction
This is a somewhat simple fix for #66731.
Under the current version of Rust, if a user has a rust file that looks like this:
```rust
fn boo (){}
async fn foo() {
boo().await;
}
fn main() {
}
```
And they attempt to run it, they will receive an error message that looks like this:
```bash
error: incorrect use of `await` --> test.rs:4:14 | 4 | boo.await(); | ^^ help: `await` is not a method call, remove the parentheses error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied --> test.rs:4:5 | 4 | boo.await(); | ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`.
```
This is not very clear.
With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:
```bash
error[E0277]: `()` is not a future.
--> test.rs:4:5
|
4 | boo().await;
| ^^^^^^^^^^^ `()` is not a future
|
= help: the trait `std::future::Future` is not implemented for `()`
= note: required by `std::future::Future::poll`
```
In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](https://github.com/rust-lang/rust/issues/66731#issuecomment-644394287). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
