124 Commits

Author SHA1 Message Date
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