Michael Goulet
99bd24e9a3
Fix span calculation on secondary_label as well
2021-12-09 09:09:39 -08:00
est31
15de4cbc4b
Remove redundant [..]s
2021-12-09 00:01:29 +01:00
Matthias Krüger
7df49eff10
Rollup merge of #91327 - dtolnay:exact, r=michaelwoerister
...
Delete an unreachable codepath from format_args implementation
2021-11-29 10:41:36 +01:00
Matthias Krüger
9715724006
Rollup merge of #90131 - camsteffen:fmt-args-span-fix, r=cjgillot
...
Fix a format_args span to be expansion
I found this while exploring solutions for rust-lang/rust-clippy#7843 .
r? `@m-ou-se`
2021-11-28 23:45:15 +01:00
David Tolnay
cc53f1356d
Delete an unreachable codepath from format_args implementation
2021-11-28 11:52:38 -08:00
Josh Triplett
8c9bfaa5f3
Stabilize format_args_capture
...
Works as expected, and there are widespread reports of success with it,
as well as interest in it.
2021-11-15 10:14:29 +01:00
Cameron Steffen
9f6a58e86b
Factor out some Vecs
2021-11-06 14:28:08 -05:00
Cameron Steffen
a9a24d5106
Don't destructure args tuple in format_args!
2021-11-06 14:28:08 -05:00
Cameron Steffen
4cfb7add77
Fix a format_args span to be expansion
2021-10-29 17:13:15 -05:00
Fabian Wolff
6490ed30e1
Improve error message for printf
-style format strings
2021-09-29 02:02:45 +02:00
bors
a0648eab36
Auto merge of #88835 - FabianWolff:issue-88770, r=petrochenkov
...
Fix error recovery in format macro parsing
Fixes #88770 . Basically, the assumption in the following comment is incorrect:
b69fe57261/compiler/rustc_builtin_macros/src/format.rs (L167-L172)
This is only true in the first iteration of the loop, when [`p.clear_expected_tokens()`](b69fe57261/compiler/rustc_builtin_macros/src/format.rs (L164)
) is called. In subsequent iterations, `p.expected_tokens` won't be empty, so `p.expect()` won't actually call `unexpected_try_recover()`:
b69fe57261/compiler/rustc_parse/src/parser/mod.rs (L487-L498)
Instead, it will call `expect_one_of()`, which _can_ recover and return `Ok()`. This PR handles this case to fix the ICE in #88770 .
2021-09-24 11:54:29 +00:00
Cameron Steffen
09b37d7433
Use ZST for fmt unsafety
...
This allows the format_args! macro to keep the pre-expansion code out of
the unsafe block without doing gymnastics with nested `match`
expressions. This reduces codegen.
2021-09-21 10:04:44 -05:00
Fabian Wolff
a8421cacfe
Fix error recovery in format macro parsing
2021-09-10 22:33:44 +02:00
Manish Goregaokar
358a018292
Rollup merge of #87441 - ibraheemdev:i-86865, r=cjgillot
...
Emit suggestion when passing byte literal to format macro
Closes #86865
2021-09-10 08:23:15 -07:00
Esteban Kuber
12ce6e9c60
Detect bare blocks with type ascription that were meant to be a struct
literal
...
Address part of #34255 .
Potential improvement: silence the other knock down errors in
`issue-34255-1.rs`.
2021-09-03 14:43:04 +00:00
ibraheemdev
f56034ec3e
emit suggestion byte literal is passed to format!
2021-08-31 17:29:42 -04:00
Cameron Steffen
975bc18481
Make Arguments constructors unsafe
2021-08-16 16:28:16 +00:00
Fabian Wolff
14f3ec2815
Fix span calculation in format strings
2021-06-07 17:42:42 +02:00
Matthias Krüger
4390a61b64
avoid full-slicing slices
...
If we already have a slice, there is no need to get another full-range slice from that, just use the original.
clippy::redundant_slicing
2021-02-16 00:31:11 +01:00
Matthias Krüger
d12a358673
use matches!() macro in more places
2020-12-24 13:35:12 +01:00
Esteban Küber
2ac89ff994
Point at named argument not found when using format_args_capture
instead of whole format string
2020-09-08 10:10:45 -07:00
Sasha
3524c3ef43
Improve recovery on malformed format call
...
If a comma in a format call is replaced with a similar token, then we
emit an error and continue parsing, instead of stopping at this point.
2020-09-02 13:18:19 +02:00
Sasha
f6d18db402
Use string literal directly when available in format
...
Previous implementation used the `Parser::parse_expr` function in order
to extract the format expression. If the first comma following the
format expression was mistakenly replaced with a dot, then the next
format expression was eaten by the function, because it looked as a
syntactically valid expression, which resulted in incorrectly spanned
error messages.
The way the format expression is exctracted is changed: we first look at
the first available token in the first argument supplied to the
`format!` macro call. If it is a string literal, then it is promoted as
a format expression immediatly, otherwise we fall back to the original
`parse_expr`-related method.
This allows us to ensure that the parser won't consume too much tokens
when a typo is made.
A test has been created so that it is ensured that the issue is properly
fixed.
2020-08-30 22:09:58 +02:00
mark
9e5f7d5631
mv compiler to compiler/
2020-08-30 18:45:07 +03:00