Deprecated symbols/features that can be removed

[jabraham17]

The following is a list of symbols/features that are deprecated that can be removed, since they have been deprecated for at least 2 releases. For many cases, I've tagged the person who added that deprecation

• CHPL_NO_CHECKS, CHPL_NO_BOUNDS_CHECKING, CHPL_NO_NIL_CHECKS, CHPL_NO_CODEGEN, CHPL_NO_COMPILE_TIME_NIL_CHECKS, CHPL_DISABLE_WARNINGS: Added by Andy, probably needs a new owner: Remove deprecation for old environment variable names #27792
• using 'require' on a Chapel source file not at module scope: @jabraham17 (Make using requires on a Chapel file at non-module scope an error #27756)
• compiler generated init for sync/atomic: @jabraham17
• returning sync/atomic by value: @jabraham17, but note there is an open design issue about restoring it in some cases: [Feature Request]: Returning atomic ... (and maybe sync/single too) by value? #27501
• this.complete(): @DanilaFe
• omitting new in a dmapped expression: Remove support for not using new in dmapped #28133
• ref-maybe-const stuff: @jabraham17. these are long overdue to be removed, but to properly remove them requires a ton of production compiler work that would be wasted when dyno comes online. But a simple fix is to just switch the deprecation to an error: Make inferring ref-maybe-const an error #28136
• implicit sync reads/writes: @jabraham17
• implicit conversions on generic formals: Added by Michael, probably needs a new owner
• make depend: @bradcray
• remove DistributedBagDeprecated: @Guillaume-Helbecque
• remove lambda - Remove support for lambda #28132
• remove CHPL_MEM/CHPL_JEMALLOC: @jabraham17
• BlockCyclic, Cyclic, Block, DimensionalDist2D, Hashed, Private, Replicated, Stencil: @bradcray
• dmap: @bradcray
• casting arrays to string is deprecated: Remove deprecated support for casting arrays to strings #28134
• disableAliasedBulkTransfer (deprecated in 2.5 by Michael, probably needs to wait for 2.7 to be removed)
• The ability to assign between two unbounded ranges with incompatible idxTypes and newRangeLiteralType: @ShreyasKhandekar
• LayoutCS: @bradcray
• Crypto.Blowfish
• HDFS: @lydia-duncan (Remove some deprecated symbols now that enough time has passed #27874)
• 'importModule' with a 'moduleContents' argument: @jabraham17 (will remove in Chapel 2.7: Remove deprecated Python.importModule method #27755)
• Toml.=: Removes the deprecated Toml.= assignments #28135
• openUrlReader/openUrlWriter with a start and/or end argument is deprecated: @Guillaume-Helbecque
• ioendian: @lydia-duncan (Remove some deprecated symbols now that enough time has passed #27874)
• OpenReaderLockingDefault/OpenWriterLockingDefault: Jeremiah, needs new owner @jabraham17
• ReadBinaryArrayReturnInt: Jeremiah, needs new owner @jabraham17
• list.first/list.last: Remove deprecations in List #28146
• deprecations related to list.parSafe=true (i.e. _warnForParSafeIndexing and .last/.first on parSafe=true): Remove deprecations in List #28146
• map.these and map.items
• Math.useNewImaginaryTrig: @DanilaFe
• Reflection.numFields: @dlongnecke-cray
• Sort deprecations: @jabraham17 / @lydia-duncan (Lydia's: Remove some deprecated symbols now that enough time has passed #27874)
• cIsoDayOfWeek: @arifthpe (owner @arifthpe, PR Remove deprecated Time.cIsoDayOfWeek config param #27747)

Other cleanups

• stale comments about deprecations in call->isPrimitive("ascii") handling in postFold and ascii runtime function
• cleanup compiler logic for deprecated kind fields in fileReader/fileWriter in determineQueriedField in prefold: @benharsh
• cleanup mentions of pragma "no doc". There is also an unused dyno test related to this: Remove references to pragma "no doc" #28137
• cleanup _abspath: Remove _abspath #28138
• cleanup stale docs about deprecations left behind by Change file.reader/file.writer locking default to false #25454: Defaults to ``true`` (*default deprecated, see warning below*). @jabraham17
• cleanup c_string_rehook/c_string` now that deprecation is complete

[arifthpe]

Are you looking for people to go ahead and assign individual items on this list to themselves?

[jabraham17]

Yes, if an item is unowned feel free to grab it (either by editing the list or leaving a comment)

[e-kayrakli]

@jabraham17

GPU reduction/scan functions are documented as potentially being deprecated, but are not yet deprecated: @e-kayrakli

Are you referring to the statement in the GPU technote?

The functions this potentially impacts are:

• gpuSumReduce
• gpuMaxReduce
• gpuMinRedice
• gpuMinLocReduce
• gpuMaxLocReduce

While the first 3 has been obviated by supporting reduce expressions and intents on GPU, the last two are still not supported. That requires a bit more plumbing in the compiler and runtime which we haven't gotten around to, yet. #24932 has more info on that.

My choice is to not deprecate anything today. Because if we do, there will be a bit of an asymmetry in how reductions are supported on the GPU. That being said, I do think that what we have right now is a bit redundant where gpuSumReduce(A) can be achieved by + reduce A.

[jabraham17]

Are you referring to the statement in the GPU technote?

Yes, that's what I was referring to. I'll go ahead and remove that from this list then

[bradcray]

Not that this is nearly the most significant thing to be proud of, but today I'm feeling proud that I've completed all the items above with my name on them!

[arifthpe]

Is this meant to be an ongoing updated issue whenever we have new things to remove, or are we just working through a one-off list still?

[jabraham17]

I think once this list is resolved, there shouldn't be new things added to it. This list has pre-edition deprecations that can be removed. With editions, anything that deprecated is done in an edition and can't be removed until the edition is removed (which is tracked by editions).

Long way to say, this issue is meant as a one-off list that we are working through (unless I missed something that should be removed)