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
Make usage of quotes in errors consistent #7578
Comments
Hey, I would be happy to improve the error messages! |
Glad to hear that! We still have to decide on how exactly this should be done, which we probably will do in tomorrows meeting. Feel free to join tomorrow (Wednesday at 15 CET, a link will be posted in gitter) in our google hangout meeting if you want to talk about it. In any case I'll update this issue with the result of the discussion! |
Thank you, @Marenz! |
Hey @Marenz! Unfortunately I could not join you for the meeting today. Have you been able to reach any agreement on this issue? |
Yes. We'd like for all user defined names to be in quotes in all error messages. Sorry I didn't update sooner. |
In single or in double quotes? |
Double quotes |
I was looking into the error messages, and I have also noticed, that a lot of custom defined errors are used. The problem is that I am not totally sure, which exact errors should be changed. Could you, please, provide me with an example of any error that has "user defined names" within it that needs to be updated? |
Here are a few examples for you: :)
here no quotes at all are used:
|
Hey, @Marenz Is this still left to work upon? I would be glad to contribute. |
@kalashshah11 I am going to push an update in a bit with all the updated error messages I could've found |
Why not introduce a |
Can't we just implement our alternative in 3 lines of code? |
Sure, that'd work |
When @erak and I talked about it we decided to make it all consistent as a first step and as a second step use a function like that. |
Sounds like a lot of extra work 😉 |
I argued along similar lines and I forgot eraks counter-argument ;) |
Well, I think I had no strong opinion on the process ;-) Would agree with @axic here and start using the helper function right away. |
What does that mean in regards to the pending PR? |
Hello! I'm new to contributing to open-source, and I saw this issue was still open. It looks like it should be resolved to me - is there still something that needs to be done that I could help out with? |
@antara-gandhi We still do not have the helper and quoting in error messages is not used consistently :) Well, we do have So my suggestion would be to start by creating the helper in |
I'm not sure the helper is that helpful (haha), we certainly do not want to escape in these cases. |
Well, it's an old issue so maybe the sentiment changed here :) Personally, I'd prefer something like m_errorReporter.typeError(
_statement.location(),
errorMsg +
". Try converting to type " +
quoted(valueComponentType->mobileType()->toString()) +
" or use an explicit conversion."
); over m_errorReporter.typeError(
_statement.location(),
errorMsg +
". Try converting to type \"" +
valueComponentType->mobileType()->toString() +
"\" or use an explicit conversion."
); or we could switch to fmtlib: #11273 (comment) :) |
I think the second version makes it much clearer what is between the strings. For the one with |
But with escaped quotes you have to parse them visually and discard as non-essential :) When I see that when skimming over the code I just skip it as something complex not worth analyzing closer while in the version with Anyway, I do not feel very strongly about this issue and I'm fine with either, just want to have a decision here so that contributors can work on it. Looks like no one was against quoting itself and it's just a matter of how we insert them (with or without a helper) so to cut the discussion short, I think it would be fine to start working on this by just inserting quotes directly. We can add a helper later if we get some consensus here. |
This issue has been marked as stale due to inactivity for the last 90 days. |
Hi everyone! This issue has been automatically closed due to inactivity. |
Our error messages are not consistent regarding the use of quotes, e.g. some quote the function name and contract name, others don't.
We should agree on how we want to do that and make it consistent everywhere.
@erak argues for double quotes
"
around all user defined names.I tend to agree.
The text was updated successfully, but these errors were encountered: