[Chapel Merge] Control numCodepoints caching with a config param

Notifications Commits
1

Branch: refs/heads/main
Revision: dab842f
Author: e-kayrakli
Log Message:

Merge pull request #18403 from e-kayrakli/string-cache-improve

Control numCodepoints caching with a config param

This PR avoids an expensive check in string implementation, but adds a secret
back door to re-enable it.

This is what I propose we should do instead of #18399

This code was added in #15870 to tighten up the ways in which strings are
created. When we added number-of-codepoints caching in #15758, we have seen that
we've had to change how strings are created in many places in the standard
libraries. I think 15870 put us in a good place, but I still have some
uneasiness around caching number of codepoints and relying on that cached value.

But the current state of things is not ideal, either: we just halt with
--boundsChecking if there's a discrepancy. With no way for the user to escape
that, it is only marginally better than letting the wrong value survive.

So, this PR adds a no-doced config param useCachedNumCodepoints = true in the
string implementation. This way, even with --boundsChecking we don't count
number of codepoints each time we need that value, but we have a way of avoiding
using the cached value if we see any issue with caching.

[Reviewed by @bradcray and @mppf]

Test:

  • [x] types/string/cachedNumCodepoints

  • [x] full standard

  • [x] full gasnet

    Modified Files:
    A test/types/string/cachedNumCodepoints/COMPOPTS
    R test/release/examples/patterns/readcsv.compopts
    R test/release/examples/patterns/readcsv.timeout
    M modules/internal/String.chpl

    Compare: Comparing 7dcec7e9883c...dab842f85010 · chapel-lang/chapel · GitHub