Commit Graph

11 Commits

Author SHA1 Message Date
Mara Bos
6c72a002a6 Add test for span of implicit format args captures. 2023-03-27 14:57:02 +02:00
Mara Bos
7f395f1eff Bless UI tests. 2023-03-27 14:56:59 +02:00
Nilstrieb
729185338f Properly allow macro expanded format_args invocations to uses captures
Originally, this was kinda half-allowed. There were some primitive
checks in place that looked at the span to see whether the input was
likely a literal. These "source literal" checks are needed because the
spans created during `format_args` parsing only make sense when it is
indeed a literal that was written in the source code directly.

This is orthogonal to the restriction that the first argument must be a
"direct literal", not being exanpanded from macros. This restriction was
imposed by [RFC 2795] on the basis of being too confusing. But this was
only concerned with the argument of the invocation being a literal, not
whether it was a source literal (maybe in spirit it meant it being a
source literal, this is not clear to me).

Since the original check only really cared about source literals (which
is good enough to deny the `format_args!(concat!())` example), macros
expanding to `format_args` invocations were able to use implicit
captures if they spanned the string in a way that lead back to a source
string.

The "source literal" checks were not strict enough and caused ICEs in
certain cases (see # 106191 (the space is intended to avoid spammy
backreferences)). So I tightened it up in # 106195 to really only work
if it's a direct source literal.

This caused the `indoc` crate to break. `indoc` transformed the source
literal by removing whitespace, which made it not a "source literal"
anymore (which is required to fix the ICE). But since `indoc` spanned
the literal in ways that made the old check think that it's a literal,
it was able to use implicit captures (which is useful and nice for the
users of `indoc`).

This commit properly seperates the previously introduced concepts of
"source literal" and "direct literal" and therefore allows `indoc`
invocations, which don't create "source literals" to use implicit
captures again.

[RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
2023-03-14 13:16:52 +00:00
Caio
d75e43c371 Move tests 2023-02-16 11:42:35 -03:00
Esteban Küber
a7597a1526 Tweak ICE message
Modify main message to be more conversational and emit one fewer note.
2023-02-07 19:17:24 +00:00
Matthias Krüger
2fdb3559c4
Rollup merge of #106805 - madsravn:master, r=compiler-errors
Suggest `{var:?}` when finding `{?:var}` in inline format strings

Link to issue: https://github.com/rust-lang/rust/issues/106572

This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.

Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of  them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.
2023-02-03 06:30:23 +01:00
Mads Ravn
f922c8395d PR fixing wrong order of format parameters in strings. Issue #106572
Adding

Adding

Fixing small issues for PR

Adding tests

Removing unused binding

Changing the wording on note

Fixing PR comment
2023-02-02 12:56:04 +01:00
Esteban Küber
62ba3e70a1 Modify primary span label for E0308
The previous output was unintuitive to users.
2023-01-30 20:12:19 +00:00
Mara Bos
47adb652d3 Update tests. 2023-01-29 20:19:26 +01:00
Nilstrieb
a8086cf9df Revert "Improve heuristics whether format_args string is a source literal"
This reverts commit e6c02aad93.

Keeps the code improvements from the PR and the test (as a known-bug).
2023-01-18 20:33:17 +01:00
Albert Larsan
cf2dff2b1e
Move /src/test to /tests 2023-01-11 09:32:08 +00:00