Organize files under src/fsharp

[dsyme]

This builds on #13113 and is draft until that is in

This organises the source files under src/fsharp into various sub-directories.

[vzarytovskii]

After this is merged, we'll need to update/rebase open PRs.

[dsyme]

This is close to ready (once green). It's a fairly simple move-and-organize.

• Utilities - general utilities
• Facilities - compiler-specific facilities such as diagnostics sink
• AbstractIL - what it says
• SyntaxTree - parsing, lexing, syntax tree
• TypedTree - the typed tree and basic ops on it
• Checking - everything to do with checking
• Optimize - everything to do with optimization and lowering
• CodeGen - IlxGen, and ILX Erase
• Driver - putting it all together
• Symbols - as before
• Service - as before
• Legacy - what it says

However the list of sub-directories mixes "build" and "source" and we may want to fix that, see below

[vzarytovskii]

• Utilities - general utilities
• Facilities - compiler-specific facilities such as diagnostics sink
• AbstractIL - what it says
• SyntaxTree - parsing, lexing, syntax tree
• TypedTree - the typed tree and basic ops on it
• Checking - everything to do with checking
• Optimize - everything to do with optimization and lowering
• CodeGen - IlxGen, and ILX Erase
• Driver - putting it all together
• Symbols - as before
• Service - as before
• Legacy - what it says

I would put this list to the docs somewhere.

[baronfel]

Another useful convention I've seen is README.md documents in the root of each folder as a guide to the purpose/intent of the contents of that folder. Perhaps overkill to have one in every folder, but localized READMEs also lend themselves to nicer browsing experiences in github, since a README in a directory is rendered automatically when viewing the code.

[vzarytovskii]

Another useful convention I've seen is README.md documents in the root of each folder as a guide to the purpose/intent of the contents of that folder. Perhaps overkill to have one in every folder, but localized READMEs also lend themselves to nicer browsing experiences in github, since a README in a directory is rendered automatically when viewing the code.

I actually really like the idea, but don't know how to make sure it's always up to date (other than having a checklist in PR template, which will be asking devs to make sure changes are reflected there).

[Lanayx]

Facilities and Utilities have too close meaning IMO

[dsyme]

I have revamped this. src/fsharp is removed and at src level we have this:

Inside the Compiler directory we have this:

I made a decision to call the directory src\Compiler and not src\FSharp.Compiler.Service . This is because

1. Typing the long name each time I look for a compiler file frankly gives me PTSD every time I type it. It just doesn't work for me. It's ok for FSharp.Build and the others, but not this component.
2. Several of the files in Compiler are used in other components as well
3. The vast majority of the important logic in the repo is in that directory (as it was in src\fsharp) and giving it the shorter name is useful.

[KevinRansom]

Looks like a fine proposal, it's gonna mess with my autopilot, but I expect I will survive :-)

[dsyme]

It's gonna mess with my autopilot, but I expect I will survive :-)

Totally. src\fsharp is hardwired into my fingers and brain. I'm literally never going to get over this.

[dsyme]

DEVGUIDE.md should be updated as well, path to the FCS project in the benchmark guide.

I think I've got everything. I did a walk over the docs and made some adjustments, and added a guide to the directories to docs/index.md (linked prominently in README.md and DEVGUIDE.md)

[smoothdeveloper]

Pretty much like what I am seeing, and concur that readme.md files are nices (in the test infrastructure, there are some).

Even if some info is outdated, it remains better than tacit knowledge (of some) and good reminder of this knowledge to all, and easy enough to update.

Hope it won't be a pain to update the pending PR's, but this refactoring work has to get in, in short turn arounds 🙂, adjusting PRs takes a separate route.

[kerams]

Merging was smooth. Didn't have to manually resolve any conflicts in my PRs.