| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Make AssocOp Copy
Found that this enum is not `Copy` while reviewing this Clippy PR: https://github.com/rust-lang/rust-clippy/pull/5727#discussion_r443761621
There shouldn't be a reason why this should not be `Copy`.
|
|
Record span of `const` kw in GenericParamKind
Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.
I am not sure how to add tests for this; any guidance in how to do so
would be appreciated :slightly_smiling_face:
|
|
|
|
Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263,
which currently records the span of a const generic param incorrectly
because the location of the `const` kw is not known.
I am not sure how to add tests for this; any guidance in how to do so
would be appreciated :slightly_smiling_face:
|
|
|
|
asm: Allow multiple template string arguments; interpret them as newline-separated
Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument.
This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`.
For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings:
```rust
fn main() {
let mut bits = [0u8; 64];
for value in 0..=1024u64 {
let popcnt;
unsafe {
asm!(
" popcnt {popcnt}, {v}",
"2:",
" blsi rax, {v}",
" jz 1f",
" xor {v}, rax",
" tzcnt rax, rax",
" stosb",
" jmp 2b",
"1:",
v = inout(reg) value => _,
popcnt = out(reg) popcnt,
out("rax") _, // scratch
inout("rdi") bits.as_mut_ptr() => _,
);
}
println!("bits of {}: {:?}", value, &bits[0..popcnt]);
}
}
```
Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands.
|
|
Fixed sentence by removing a word.
|
|
pprust uses `print_string` to write out the template string, and
`print_string` already calls `escape_debug`, so `impl fmt::Display for
InlineAsmTemplatePiece` shouldn't do an additional `escape_debug`.
This fixes a pretty-printing bug that translated
`asm!("...\n...")`
to
`asm!("...\\n...")`
|
|
Clean up type alias impl trait implementation
- Removes special case for top-level impl trait
- Removes associated opaque types
- Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types.
- Handle lifetimes in type alias impl trait more uniformly with other parameters
cc #69323
cc #63063
Closes #57188
Closes #62988
Closes #69136
Closes #73061
|
|
Track span of function in method calls, and use this in #[track_caller]
Fixes #69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
|
|
|
|
Fix more clippy warnings
Fixes more of:
clippy::unused_unit
clippy::op_ref
clippy::useless_format
clippy::needless_return
clippy::useless_conversion
clippy::bind_instead_of_map
clippy::into_iter_on_ref
clippy::redundant_clone
clippy::nonminimal_bool
clippy::redundant_closure
clippy::option_as_ref_deref
clippy::len_zero
clippy::iter_cloned_collect
clippy::filter_next
r? @Dylan-DPC
|
|
|
|
Fixes #69977
When we parse a chain of method calls like `foo.a().b().c()`, each
`MethodCallExpr` gets assigned a span that starts at the beginning of
the call chain (`foo`). While this is useful for diagnostics, it means
that `Location::caller` will return the same location for every call
in a call chain.
This PR makes us separately record the span of the function name and
arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This
`Span` is passed through HIR lowering and MIR building to
`TerminatorKind::Call`, where it is used in preference to
`Terminator.source_info.span` when determining `Location::caller`.
This new span is also useful for diagnostics where we want to emphasize
a particular method call - for an example, see
https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
|
|
Fixes more of:
clippy::unused_unit
clippy::op_ref
clippy::useless_format
clippy::needless_return
clippy::useless_conversion
clippy::bind_instead_of_map
clippy::into_iter_on_ref
clippy::redundant_clone
clippy::nonminimal_bool
clippy::redundant_closure
clippy::option_as_ref_deref
clippy::len_zero
clippy::iter_cloned_collect
clippy::filter_next
|
|
Previously, we would parse `struct Foo where;` and `struct Foo;`
identically, leading to an 'empty' `where` clause being omitted during
pretty printing. This will cause us to lose spans when proc-macros
involved, since we will have a collected `where` token that does not
appear in the pretty-printed item.
We now explicitly track the presence of a `where` token during parsing,
so that we can distinguish between `struct Foo where;` and `struct Foo;`
during pretty-printing
|
|
|
|
Improve inline asm error diagnostics
Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.
The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.
Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.
Fixes #72664
Fixes #71639
r? @petrochenkov
### Old style
```rust
#![feature(llvm_asm)]
fn main() {
unsafe {
let _x: i32;
llvm_asm!(
"mov $0, $1
invalid_instruction $0, $1
mov $0, $1"
: "=&r" (_x)
: "r" (0)
:: "intel"
);
}
}
```
```
error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction'
invalid_instruction ecx, eax
^~~~~~~~~~~~~~~~~~~
--> src/main.rs:6:9
|
6 | / llvm_asm!(
7 | | "mov $0, $1
8 | | invalid_instruction $0, $1
9 | | mov $0, $1"
... |
12 | | :: "intel"
13 | | );
| |__________^
```
### New style
```rust
#![feature(asm)]
fn main() {
unsafe {
asm!(
"mov {0}, {1}
invalid_instruction {0}, {1}
mov {0}, {1}",
out(reg) _,
in(reg) 0i64,
);
}
}
```
```
error: invalid instruction mnemonic 'invalid_instruction'
--> test.rs:7:14
|
7 | invalid_instruction {0}, {1}
| ^
|
note: instantiated into assembly here
--> <inline asm>:3:14
|
3 | invalid_instruction rax, rcx
| ^^^^^^^^^^^^^^^^^^^
```
|
|
|
|
This reverts commit 7a4c1865fb2f58c57e3f09645515dec8be3022c6.
|
|
This reverts commit 2af0218bf1ffca0750a352554f20a07b760a30a8.
|
|
This reverts commit 5685e4dd90ad2f4978c63b9097f0b568e4ce6e5c.
|
|
|
|
|
|
|
|
|
|
Some tokens need to be broken in a loop until we reach
'unbreakable' tokens.
|
|
Fixes #68489
When checking two `TokenStreams` to see if they are 'probably equal',
we ignore the `IsJoint` information associated with each `TokenTree`.
However, the `IsJoint` information determines whether adjacent tokens
will be 'glued' (if possible) when construction the `TokenStream` - e.g.
`[Gt Gt]` can be 'glued' to `BinOp(Shr)`.
Since we are ignoring the `IsJoint` information, 'glued' and 'unglued'
tokens are equivalent for determining if two `TokenStreams` are
'probably equal'. Therefore, we need to 'unglue' all tokens in the
stream to avoid false negatives (which cause us to throw out the cached
tokens, losing span information).
|
|
|
|
|
|
Julian-Wollersberger:literal_error_reporting_cleanup, r=petrochenkov
Literal error reporting cleanup
While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up.
This PR is probably best reviewed commit by commit.
I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now.
I could open a PR for Rust-Analyzer when this one lands.
But how do I open a PR for clippy? (Git submodules are frustrating to work with)
|
|
|
|
Remove ast::{Ident, Name} reexports.
The reexport of `Symbol` into `Name` confused me.
|
|
|
|
|
|
doc: this resulted in a link pointing to a non-existent target
|
|
|
|
|
|
fix -Zast-json to output correct JSON form
fixes #71086 (Reverts some of the changes made in #70215)
JSON output (from an empty library) after fix has something for **"id"** field
```shell
lonelyjoe@lonelyjoe-desktop:~/workspace/empty_lib/src$ rustc lib.rs -Zast-json
```
```json
{
"module":{
"inner":{
"lo":0,
"hi":94
},
"items":[
{
"attrs":[
{
"kind":{
"variant":"Normal",
"fields":[
{
"path":{
"span":{
"lo":0,
"hi":0
},
"segments":[
{
"ident":{
"name":"prelude_import",
"span":{
"lo":0,
"hi":0
}
},
"id":3,
"args":null
}
]
},
"args":"Empty"
}
]
},
"id":null,
"style":"Outer",
"span":{
"lo":0,
"hi":0
}
}
],
"id":4,
"span":{
"lo":0,
"hi":0
},
"vis":{
"node":"Inherited",
"span":{
"lo":0,
"hi":0
}
},
"ident":{
"name":"",
"span":{
"lo":0,
"hi":0
}
},
"kind":{
"variant":"Use",
"fields":[
{
"prefix":{
"span":{
"lo":0,
"hi":0
},
"segments":[
{
"ident":{
"name":"{{root}}",
"span":{
"lo":0,
"hi":0
}
},
"id":5,
"args":null
},
{
"ident":{
"name":"std",
"span":{
"lo":0,
"hi":0
}
},
"id":6,
"args":null
},
{
"ident":{
"name":"prelude",
"span":{
"lo":0,
"hi":0
}
},
"id":7,
"args":null
},
{
"ident":{
"name":"v1",
"span":{
"lo":0,
"hi":0
}
},
"id":8,
"args":null
}
]
},
"kind":"Glob",
"span":{
"lo":0,
"hi":0
}
}
]
},
"tokens":null
},
{
"attrs":[
{
"kind":{
"variant":"Normal",
"fields":[
{
"path":{
"span":{
"lo":0,
"hi":0
},
"segments":[
{
"ident":{
"name":"macro_use",
"span":{
"lo":0,
"hi":0
}
},
"id":9,
"args":null
}
]
},
"args":"Empty"
}
]
},
"id":null,
"style":"Outer",
"span":{
"lo":0,
"hi":0
}
}
],
"id":10,
"span":{
"lo":0,
"hi":0
},
"vis":{
"node":"Inherited",
"span":{
"lo":0,
"hi":0
}
},
"ident":{
"name":"std",
"span":{
"lo":0,
"hi":0
}
},
"kind":{
"variant":"ExternCrate",
"fields":[
null
]
},
"tokens":null
}
],
"inline":true
},
"attrs":[
],
"span":{
"lo":0,
"hi":94
},
"proc_macros":[
]
}
```
|
|
|
|
|
|
|
|
|
|
Tweak output of type params and constraints in the wrong order
r? @Centril @varkor
|
|
|
|
|
|
When encountering constraints before type arguments or lifetimes,
suggest the correct order.
|
|
|
|
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
|
