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: Added by Jeremiah, needs a new owner
• 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.
• 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 CHPL_MEM/CHPL_JEMALLOC: @jabraham17
• BlockCyclic, Cyclic, Block, DimensionalDist2D, Hashed, Private, Replicated, Stencil: @bradcray
• dmap: @bradcray
• casting arrays to string is deprecated: Added by Jeremiah, needs a new owner
• 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
• 'importModule' with a 'moduleContents' argument: @jabraham17 (will remove in Chapel 2.7: Remove deprecated Python.importModule method #27755)
• Toml.=
• openUrlReader/openUrlWriter with a start and/or end argument is deprecated: @Guillaume-Helbecque
• ioendian: @lydia-duncan
• OpenReaderLockingDefault/OpenWriterLockingDefault: Jeremiah, needs new owner @jabraham17
• ReadBinaryArrayReturnInt: Jeremiah, needs new owner @jabraham17
• list.first/list.last: @DanilaFe
• deprecations related to list.parSafe=true (i.e. _warnForParSafeIndexing and .last/.first on parSafe=true)
• map.these and map.items
• Math.useNewImaginaryTrig: @DanilaFe
• Reflection.numFields: @dlongnecke-cray
• Sort deprecations: @jabraham17 / @lydia-duncan
• 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
• cleanup _abspath
• 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