-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Alternate fix for complex() parsing #17384
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
Conversation
Signed-off-by: Jeff Epler <jepler@gmail.com>
If a complex literal had a negative real part and a positive complex part, it was not parsed properly. Co-Authored-By: ComplexSymbol <141301057+ComplexSymbol@users.noreply.github.com> Signed-off-by: Jeff Epler <jepler@gmail.com>
Signed-off-by: Jeff Epler <jepler@gmail.com>
Code size report:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #17384 +/- ##
=======================================
Coverage 98.54% 98.54%
=======================================
Files 169 169
Lines 21898 21903 +5
=======================================
+ Hits 21579 21584 +5
Misses 319 319 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
When the CI passes, let's see how big the code size change is. |
A sign character is now required when a literal passed to complex() has both a real and imaginary part. Signed-off-by: Jeff Epler <jepler@gmail.com>
64ddc9f
to
e8d0098
Compare
Updated. I have seen this technique used but since I didn't see a diagnostic on the unix build (which allows it as an extension) I didn't realize it was needed here. Future gcc will have a way to enable a diagnostic about this incorrect label usage even when not running in pedantic mode: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669243.html |
Thanks for opening this for a comparison with #17383. Considering the relatively large increase in code size, I'll close this in favour of #17383. At least with this PR, |
Makes perfect sense, thanks! |
In micropython#17384 it was decided that fixing this difference was not worth the code size increase.
In micropython#17384 it was decided that fixing this difference was not worth the code size increase.
In micropython#17384 it was decided that fixing this difference was not worth the code size increase. Signed-off-by: Jeff Epler <jepler@gmail.com>
In micropython#17384 it was decided that fixing this difference was not worth the code size increase. Signed-off-by: Jeff Epler <jepler@gmail.com>
In #17384 it was decided that fixing this difference was not worth the code size increase. So document it instead. Signed-off-by: Jeff Epler <jepler@gmail.com>
In micropython#17384 it was decided that fixing this difference was not worth the code size increase. So document it instead. Signed-off-by: Jeff Epler <jepler@gmail.com>
In micropython#17384 it was decided that fixing this difference was not worth the code size increase. So document it instead. Signed-off-by: Jeff Epler <jepler@gmail.com>
In contrast to #17383 this one also fixes parsing for
complex("1 1j")
where a sign character does not occur between the real and imaginary parts of a number with both parts. It almost certainly makes the code grow more. Please feel free to close this if the code growth isn't worth the benefit. If so, a section should probably be added to the difference page in the docs.