HCR: better documentation

doc/nimc.rst

@@ -414,94 +414,6 @@ the generated C contains code to ensure that proper stack traces with line
 number information are given if the program crashes or an uncaught exception
 is raised.
 
-Hot code reloading
-------------------
-
-The `hotCodeReloading`:idx: option enables special compilation mode where
-changes in the code can be applied automatically to a running program.
-The code reloading happens at the granularity of an individual module.
-When a module is reloaded, any newly added global variables will be
-initialized, but all other top-level code appearing in the module won't
-be re-executed and the state of all existing global variables will be
-preserved. One can use the special event handlers ``beforeCodeReload`` and
-``afterCodeReload`` to reset the state of a particular variable or to force
-the execution of certain statements:
-
-.. code-block:: Nim
-  var
-   settings = initTable[string, string]()
-   lastReload: Time
-
-  for k, v in loadSettings():
-    settings[k] = v
-
-  initProgram()
-
-  afterCodeReload:
-    lastReload = now()
-    resetProgramState()
-
-On each code reload, Nim will first execute all `beforeCodeReload`:idx:
-handlers registered in the previous version of the program and then all
-`afterCodeReload`:idx handlers appearing in the newly loaded code. Please note
-that any handlers appearing in modules that weren't reloaded will also be
-executed. To prevent this behavior, one can guard the code with the
-`hasModuleChanged()`:idx: API:
-
-.. code-block:: Nim
-  import mydb
-
-  var myCache = initTable[Key, Value]()
-
-  afterCodeReload:
-    if hasModuleChanged(mydb):
-      resetCache(myCache)
-
-The hot code reloading is based on dynamic library hot swapping in the native
-targets and direct manipulation of the global namespace in the JavaScript
-target. The Nim compiler does not specify the mechanism for detecting the
-conditions when the code must be reloaded. Instead, the program code is
-expected to call `performCodeReload()`:idx every time it wishes to reload
-its code.
-
-It's expected that most projects will implement the reloading with a suitable
-build-system triggered IPC notification mechanism, but a polling solution is
-also possible through the provided `hasAnyModuleChanged()`:idx API.
-
-In order to access ``beforeCodeReload``, ``afterCodeReload``, ``hasModuleChanged``
-or ``hasAnyModuleChanged`` one must import the `hotcodereloading`:idx module.
-
-**Usage in Native projects:**
-
-Native projects using the hot code reloading option will be implicitly
-compiled with the `-d:useNimRtl` option and they will depend on both
-the ``nimrtl`` library and the ``nimhcr`` library which implements the
-hot code reloading run-time.
-
-All modules of the project will be compiled to separate dynamic link
-libraries placed in the ``nimcache`` directory. Please note that during
-the execution of the program, the hot code reloading run-time will load
-only copies of these libraries in order to not interfere with any newly
-issued build commands.
-
-The main module of the program is considered non-reloadable. Please note
-that procs from reloadable modules should not appear in the call stack of
-program while ``performCodeReload`` is being called. Thus, the main module
-is a suitable place for implementing a program loop capable of calling
-``performCodeReload``.
-
-Please note that reloading won't be possible when any of the type definitions
-in the program has been changed. When closure iterators are used (directly or
-through async code), the reloaded refinitions will affect only newly created
-instances. Existing iterator instancess will execute their original code to
-completion.
-
-**Usage in JavaScript projects:**
-
-Once your code is compiled for hot reloading, the ``nim-livereload`` NPM
-package provides a convenient solution for implementing the actual reloading
-in the browser using a framework such as [LiveReload](http://livereload.com/)
-or [BrowserSync](https://browsersync.io/).
 
 
 DynlibOverride