Skip to content
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

fix Issue 22929 - importC: extern array with unknown length gives bou… #13902

Merged
merged 1 commit into from
Mar 29, 2022

Conversation

WalterBright
Copy link
Member

…nds errors

This was actually two problems. The first test case is handled by lines optimize.c lines 555-561, the second test case the rest.

@WalterBright WalterBright added the Feature:ImportC Pertaining to ImportC support label Mar 28, 2022
@dlang-bot
Copy link
Contributor

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close Bugzilla Severity Description
22929 normal importC: extern array with unknown length gives bounds errors

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#13902"

@@ -8472,6 +8472,19 @@ private extern (C++) final class ExpressionSemanticVisitor : Visitor
// OR it in, because it might already be set for C array indexing
exp.indexIsInBounds |= bounds.contains(getIntRange(exp.e2));
}
else if (auto ve = exp.e1.isVarExp())
{
if (sc.flags & SCOPE.Cfile && t1b.ty == Tsarray)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micro-optimization: swap this condition with the one above. Compiling C files occurs less frequent than compiling D files.

Also, I am a bit worried for the effect that all of these C file conditions have on the compilation of normal D code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.

I work to minimize these changes.

if (!se.var.isReference() &&
!se.var.isImportedSymbol() &&
se.var.isDataseg() &&
se.var.isCsymbol())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this situation I have to mentally load myself with all of the previous conditions and then at the end I see that it applies only to C symbols. Why not start with this condition(preferably put it in the outer if)? That way, it becomes clear that what follows applies to C land. This should be a general rule.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put isCsymbol() at the end because it is slower.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized the isCsymbol() isn't necessary and removed it.

@WalterBright WalterBright force-pushed the fix22929 branch 2 times, most recently from 2ea9776 to 3f11a41 Compare March 28, 2022 18:57
@WalterBright
Copy link
Member Author

This is blocking fixing https://issues.dlang.org/show_bug.cgi?id=22935 which is strongly related.

@WalterBright WalterBright added the Review:Blocking Other Work review and pulling should be a priority label Mar 29, 2022
@RazvanN7 RazvanN7 merged commit 6ddeba4 into dlang:master Mar 29, 2022
@WalterBright WalterBright deleted the fix22929 branch March 29, 2022 08:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:ImportC Pertaining to ImportC support Review:Blocking Other Work review and pulling should be a priority Severity:Bug Fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants