Options:

* Fully implicit includes (i.e. all source files in the directory
  get recursively included)
    - Problem: Does not work with "junk" folders or "junk files".
        - Could have an ignore file of some kind
          (or a pointer to an existing file, e.g. `.gitignore`)
        - Could skip any file/folder that begins with an underscore.
    - Problem: Untracked files can remain when switching between
      GIT/VCS branches, or when stashing (tracked) changes.
    - Problem: Can be really slow if there's some very deep non-source
      directory, in particular if it's on a slow filesystem.
* Fully implicit includes with some ignore-file.
    - As above, but gives a possibility to solve some of the problems.
* Reverse includes, but require some project-specific "header" in each
  file, or it will be ignored.
    - The header could also be a commit-ID (of when the file was first added),
      and the compiler could check for its presence in the VCS history.
      But of course, this adds complexity and could be really really slow
      with centralized VCS'es.
    - Problem: Perhaps not very intuitive?
    - Problems: More or less the same as for "fully implicit includes".
* Semi-implicit includes.
    - E.g. include files in the same directory, but only traverse into
      subdirectories if explicitly included.
    - Problem: Untracked files...
* Include files of referenced classes.
    - E.g. if class `A` is referenced somewhere, then attempt to
      include `A.fileext`
    - Subdirectories would require namespaces.
    - Utility/multi-class files still have to be included explicitly.
    - Problem: Harder to do parallel parsing
    - Problem: Forgotten/unused files will not be detected
    - Problem: Classes that are defined both in "utility source files"/
      lowercase files and also as their own source file will not give any
      error.
* Pull information from some other file list (e.g. SPDX list etc.)
* Pull information from VCS (e.g. `git ls-files`)
    - Problem: Locks in to specific VCS'es
        - could fall back to including all files if VCS is unsupported
    - Problem: Locks in to a specific workflow: E.g. whether files
      must be in intent-to-add, staged or committed to be seen by the
      compiler (intent-to-add is probably the best idea, but not all
      VCS'es support that, some have only untracked-vs-committed, e.g.
      CVS and SVN)
        - could fall back to including all files if VCS is impossible
          to support due to lack to a staging/intent-to-add area.
    - Problem: Executes VCS binaries that might have vulnerabilities
* File list in sepearate file
    - Similar to "per-directory file list file"
    - Problem: (Additional) Very likely to cause lots of merge conflicts.
* Per-directory file list file
    - Can fall back to implicit includes (with a warning) if the
      file list is missing or incomplete.
    - Problem: Could conflict with other languages if they use the
      same filename, and a project puts sources from both languages
      into the same directory (how likely is this to happen?)
    - Problem: Can cause some merge conflicts
* File list in main source file
* Uses/import list in each source file


Possible "combined" solution?
-----------------------------
(But dependencies should still be listed in a central file)

    # Using a whole-file class
    use SomeClass
    # Using a class in a multi-class file
    use utils.Point
    # Using a class in a dependency
    use somedep.Class
    # Perhaps this syntax could be extended with an optional version,
    # to force an older version than specified in the depends file?
    # (could be problematic if passed to another class...)
    # (also, is there any real need for it?)
    use somedep.Class 0.9
    # Using an external extension of a class
    extend utils.String

File list somehow generated by GIT?
-----------------------------------
Could GIT or other VCS'es generate the file list?
It would be good if there could be a standard way of doing this,
because it's really the same problem for many other proglangs also.

Inverse solution: Ignore-lists generated by a per-user/system command
---------------------------------------------------------------------
Include all (non-excluded) source files, but don't descend into directories.
Have the ability to define per-user/per-system commands that allows the user
to ignore e.g. untracked GIT files.

Example config file, e.g. ~/.config/newproglang/compiler.conf

    [ignore]
    git.condition = exists .git
    git.file-list-command = git ls-files -o
    git.invalidate-if = modified .git/HEAD

But is this fast enough? See caching below.

Follow-up problem:
* Should directories serve as modules, or as some kind of namespaces?

Caching
-------
Could generate a file-list cache file, and track file modification there,
e.g. (size,lastmod).

Only if an unknown class is found it's necessary to perform a scan.
The scan could stop when all missing classes have been found.

This isn't fool-proof, though. Stashing and creating files could probably
trigger cache inconsistencies.

Trivial solution (best?)
------------------------
Use file lists, perhaps nested ones with directories also.

If unbounds identifiers are detected:
* Either report an error.
* Or, report a warning and trigger a search in the directories
  (but not in arbitrary nested directories). Parse any matching files.

Have a `slul2 fix f` command to generate filelists (this could work with
dependencies and exports also).

Suggest the `slul2 fix f` command in the compilation error message.