Remove dmap and deprecated distributions

[bradcray]

This PR removes the deprecated symbols related to distributions, layouts, and the dmap type. Specifically, it removes:

• the dmap type
• distributions that had previously been implemented as classes and been deprecated (e.g., Block was deprecated in favor of blockDist)
• the deprecated LayoutCS module
• a deprecated config const in BlockDist.chpl, disableAliasedBulkTransfer.

It also updates tests and documentation to remove references to the dmap type even in places where it doesn't terribly matter.

In more detail:

• I simply removed all deprecated distributions (BlockCyclic, Block, Cyclic, DimensionalDist2D, Hashed, Private, Replicated, Stencil), associated comments, and the aforementioned config

• Similarly, I removed the LayoutCS module and all references to it

• The dmap type was still used to create the logical singleton defaultDist, as it still provides the value-based wrapping around the DefaultDist class. Ultimately, DefaultDist should be rewritten to be a record, but here I took the simpler and more minimal approach of renaming the dmap type to chpl_dmap, effectively making it an internal symbol. Beyond updating defaultDist's use of it, this also required updating Dyno to recognize the new name, as it is currently special-cased there.

• I removed a pair of helper routines in ChapelArray.chpl that existed merely to keep the dmap type working while deprecated.

• I removed tests in the test/deprecated directory related to these features

• Interestingly, the removal of disableAliasedBulkTransfer caused BlockDist.chpl to go from being a non-dead module to a dead one; presumably, the presence of a config in a module prevents it from being dead-code eliminated since it represents a (potential) user-facing feature. This required updates to tests that were sensitive to module init/deinit order and counts of dead modules, such as:

  • test/modules/sungeun/init/printModuleInitOrder.chpl
  • test/modules/vass/deinit-order-modules.verbose.chpl
  • test/optimizations/deadCodeElimination/elliot/countDeadModules.chpl

• In SparseBlockDist.getDefaultSparseDist(), I changed a case that relied on dmap into a halt() because I believe it was only used for (old, now removed) class-based distributions, so should no longer be hit in practice. In essence, the halt() serves as an always-on assertion.

• I added a pair of records to wrap class-based distributions to DSIUtil.chpl, similar to how chpl_PrivatizedDistHelper did this for the Block, Cyclic, etc. classes when they were being converted into records. One is for wrapping a rectangular distribution, the other for associative (chpl__rectLayoutHelper and chpl__assocLayoutHelper, respectively). At present, these are only used by tests in the test system that created custom distribution classes, though if we had class-based layouts, they could be used there as well to convert to record-based implementations. That said, if writing a new record-based distribution today, it should simply be written as a record, which would obviate the need for wrapping a class. Put another way, this is just a trick to minimize the amount of code that needs to be rewritten; with more effort, the tests that create custom distributions could/should be rewritten to simply use a record type as well.

• Tests with custom class-based distributions that required updates to use record-based distributions (and leverage the above helpers) included:

  • MyDist => myDist in test/arrays/dmapped-new-error-class.chpl
  • MyDist => myDist in test/distributions/bradc/wrongDomForDist/*.chpl
  • GlobalDistribution => globalDistribution in test/domains/vass/no-dom-field-error.chpl
  • AccumStencil => accumStencil in test/studies/comd/elegant/arrayOfStructs/util/*.chpl

• I updated tests or code patterns that relied on new dmap(new DefaultDist()) to simply use defaultDist instead, such as in test/unstable/dmapped-sparse.chpl and test/users/engin/sparse_bulk/sparseBulkBoundsCheck.chpl

• I simplified an error message in normalize.cpp that referred to new dmap() to avoid it and to avoid worrying about class-based distributions, which shouldn't exist anymore while also improving the error message to name the distribution type that was used rather than relying on a placeholder. I similarly removed test/arrays/dmapped-new-error-class.chpl which served only to lock in the version of the error message for class-based distributions.

• I also removed test/distributions/diten/domainMethodNewDist.chpl which seemed to serve no particular purpose in a dmap-less world

• I removed index entries in the spec related to the dmap type and updated some examples of dmapped blockDist() to read dmapped new blockDist() as well, which is now required

• I removed obvious references to the dmap type from doc/rst/technotes/dsi.rst and made some simple edits to the document to reflect the current record-based assumption about distribution type, but it's almost certain that more about this docuement should be refreshed or cleaned up w.r.t. record-based distributions.

• I also updated a bunch of tests that weren't running or weren't consequential or that mentioned dmap in their comments to avoid the term, primarily for the sake of reducing false positives when looking for ongoing references to dmap

[jabraham17]

Looks good!

Just noting that I still see mentions of dmap in the docs

• doc/rst/technotes/dsi.rst
• doc/rst/language/spec/domain-maps.rst

And those should probably be updated as well

[jabraham17]

This error message is now incorrect, there is no dmap a user can use

[bradcray]

Also a good catch! I'm going to remove this test (in addition to removing the compiler logic that printed new dmap(), as it was specific to a time when some, but not all, distributions were converted to classes.

While here, I also updated the error message to print the actual distribution type rather than <DistName> which seems like an obvious/simple improvement.

[bradcray]

@jabraham17 : Thanks for catching those cases I missed. I used your comments to look for other references to dmap that I'd missed using:

git grep `new dmap`
git grep dmap | grep -v dmapped | grep -v chpl_dmap | grep -v third-party

This isn't perfect since a line of code with dmap and dmapped on a single line could occur and slip past my checks, but it's much more complete than I'd been before.

This resulted in me getting into a bunch of tests and comments that weren't particularly important, but I like that it left things in a cleaner condition w.r.t. dmap. I don't know if it's worth your time to review the delta between your last review and this one or not. Most of it is somewhere between "trivial" and "not terribly interesting", but I wanted to at least give you the chance to take a look if you were interested (I'm working on refreshing the OP now).

[jabraham17]

I don't know how well sphinx will render this, I don't think it can handle newlines in a .. method. Did you check it?