[Chapel Merge] remove cruft accidentally added to doc

stonea · December 22, 2021, 7:04pm

Branch: refs/heads/main
Revision: 873ddff
Author: stonea
Link: remove cruft accidentally added to doc by stonea · Pull Request #18897 · chapel-lang/chapel · GitHub
Log Message:

Merge pull request #18897 from stonea/remove_doc_cruft

remove cruft accidentally added to doc

I inserted some cruft while testing that modifying a file updated the doc where I expected it to. See this comment:

github.com/chapel-lang/chapel

Separate _domain record out into its own file.

chapel-lang:main ← stonea:separateDomain_onlyRecord

opened 06:01PM - 09 Dec 21 UTC

stonea

+2124 -2068

I've created a new internal module `ChapelDomain.chpl` and moved the `_domain` r…ecord from `ChapelArray.chpl` to there. This is necessary as we want the language-spec doc for arrays and domains to generate independent of one another and its easiest of I can get chapel docs to generate separate .rst files for each. For more info about what I'm trying to accomplish see: https://github.com/Cray/chapel-private/issues/2549 and https://github.com/chapel-lang/chapel/issues/18027 ~~In this PR I'm only migrating the `_domain` record type. Really~~ we should also: * ~~Move all the domain-related free functions into `ChapelDomain.chpl`~~ * Move _distribution and its related free functions into their own `ChapelDistribution.chpl` file. * If there are common utility functions in `ChapelArray.chpl` that are used among arrays, domains, and distributions then they should probably go into their own `ChapelArrayDomDistUtils.chpl` (or some better named) file. ~~I wanted to accomplish the first of those bullet points in this PR. You can see my attempt here: https://github.com/stonea/chapel/commit/df45f38dc94081ca10db3b629b0fe193b497cb89 But this results in a slew of test failures in paratests (I'll list them in a comment). Anyway, I'd like to get a PR submitted this release just so I'm not blocked on the doc issue.~~ ~~To reviewers:~~ * ~~Do you feel its ok for me to do this partial refactoring? I'd argue this is moving things in the right direction, but I could understand the opinion that leaving things spread across two files is adding not removing technical debt.~~ * ~~As much as I'd like to say I'll get the more complete refactoring done next sprint, unless I get feedback that this is high priority, I don't think I'd want to spend more than a day attempting it; so unless the bug fixes are simple there's a chance things get left in this partially refactored state.~~ * ~~I haven't dug into any of the failures (in the branch where I do the more total refactoring) yet but I will take a look to make sure there isn't a trivial fix.~~ **Edit**: I was able to get the "larger" refactoring to work so ignore the strikethroughed text (keeping on the main PR message for historical reasons). Meta note: is this good PR practice or at this point do you feel I should just cancel this one and open a new one? Meta-meta note: The branch name is now `separateDomain_onlyRecord`, which is out of date. Anyone know of a way to update an open GitHub PR to use another branch? To reviewers -- I guess the main thing to review now is whether you feel I made the right "cut" or not. I realize it's a long list, but if you wouldn't mind take a quick look and let me know if there's any function migrated to `ChapelDomain.chpl` that you feel shouldn't belong there or any function remaining in `ChapelArray.chpl` that seems exclusively domain related.

Thankfully @cassella caught it.

[Reviewed by nobody since the change is trivial (just removing a comment)]

Modified Files:
M test/release/examples/primers/domains.chpl

Compare: https://github.com/chapel-lang/chapel/compare/73e72ba6d5f4...873ddffc1abf