-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest to remove prefix b
in cfg attribute lint string
#54929
Conversation
Woah, you're fast! Though I do wonder why there's no associated test with this change? |
This comment has been minimized.
This comment has been minimized.
These numerous ad-hoc "E-Easy" diagnostic PRs steadily fill the compiler with garbage that someone will have to eventually clean up. |
eac0b61
to
9059b49
Compare
This comment has been minimized.
This comment has been minimized.
39068c7
to
e48b515
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
859f31c
to
e516b6f
Compare
☔ The latest upstream changes (presumably #54969) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code change looks good to me, it doesn't seem to be introducing much more complexity than is already there, although I agree that this could potentially be generalized to all cases where a byte string is encountered where a &str is expected. I believe we already have ad-hoc handling for some of the cases where that happens, but having a centralized methodology would be useful.
With this said, I do fall on the camp of "a bit of tech-debt for huge usability gains are worth it", but the gains need to be extensive. This case in particular doesn't seem to be something that will be stumbled upon by somebody learning the language before learning the difference between ""
and b""
, so I could be easily convinced of not merging this PR and wait for the general solution (although part of the change actually cleans stuff up).
@petrochenkov do you want to take on the review for this PR? I'd defer to your final choice. As for generalizing, I feel that we can move a lot of these ad-hoc diagnostics further up in the parser by having a more complex version of Parser::eat(&mut self, TokenKind)
that also takes some textual info for diagnostics, and also checks for "confusables"—not only single tokens that look alike, like ;
and :
, but also cases like this one (b""
/""
). What do you think?
--> $DIR/cfg-attr-syntax-validation.rs:22:11 | ||
| | ||
LL | #[cfg(a = 10)] //~ ERROR literal in `cfg` predicate value must be a string | ||
LL | #[cfg(a = 10)] //~ ERROR unsupported literal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change feels like a slight step backwards, from a very specific diagnostic towards a more general one... Shouldn't be a blocker.
@@ -1326,6 +1326,14 @@ impl LitKind { | |||
} | |||
} | |||
|
|||
/// Returns true if this literal is byte literal string false otherwise. | |||
pub fn is_bytestr(&self) -> bool { | |||
match self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to use if let
here?
I don't think this needs to go into parser? |
src/libsyntax/attr/builtin.rs
Outdated
@@ -27,7 +27,7 @@ enum AttrError { | |||
UnsupportedLiteral | |||
} | |||
|
|||
fn handle_errors(diag: &Handler, span: Span, error: AttrError) { | |||
fn handle_errors(diag: &Handler, span: Span, error: AttrError, is_bytestr: bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is_bytestr
is only used with AttrError::UnsupportedLiteral
, so it can be made its part - AttrError::UnsupportedLiteral(bool /* is_bytestr */)
@@ -461,8 +490,13 @@ pub fn cfg_matches(cfg: &ast::MetaItem, sess: &ParseSess, features: Option<&Feat | |||
MetaItemKind::List(..) => { | |||
error(cfg.span, "unexpected parentheses after `cfg` predicate key") | |||
} | |||
MetaItemKind::NameValue(lit) if !lit.node.is_str() => { | |||
error(lit.span, "literal in `cfg` predicate value must be a string") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you keep the old wording?
AttrError::UnsupportedLiteral
can be extended to keep string fragments, and the resulting error message can be combined from them:
AttrError::UnsupportedLiteral(where, expected)
span_err("literal in {} must be a {}", where, expected)
AttrError::UnsupportedLiteral("`cfg` predicate value", "string")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would give other UnsupportedLiteral
errors better messages as well.
I've left a couple of comments, otherwise LGTM. |
1f796b2
to
9038c71
Compare
This comment has been minimized.
This comment has been minimized.
3 similar comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
src/test/ui/conditional-compilation/cfg-attr-syntax-validation.rs
Outdated
Show resolved
Hide resolved
src/test/ui/conditional-compilation/cfg-attr-syntax-validation.stderr
Outdated
Show resolved
Hide resolved
Co-Authored-By: csmoe <csmoe@msn.com>
Co-Authored-By: csmoe <csmoe@msn.com>
@bors r+ |
📌 Commit 81a609b has been approved by |
⌛ Testing commit 81a609b with merge 5d65ad1b67c016e67e7ffde084d2d33a830ed34a... |
💔 Test failed - status-travis |
This comment has been minimized.
This comment has been minimized.
☀️ Test successful - status-appveyor, status-travis |
Closes #54926
r? @estebank