refactor: drop bitcode support

.github/check_info_nodes_support.sh

@@ -109,29 +109,6 @@ while IFS= read -r line; do
     print_message "* \`build$name()\` not found in \`src/lib/AST/ASTVisitor.cpp\`"
   fi
 
-  # `src/lib/AST/AnyBlock.hpp` should define the `${name}Block` type
-  # Look for the string `${name}Block` in the file
-  if ! grep -q "${name}Block" "$MRDOCS_ROOT/src/lib/AST/AnyBlock.hpp"; then
-    print_message_once "## ${name}Info"
-    print_message "* \`${name}Block\` not found in \`src/lib/AST/AnyBlock.hpp\`"
-  fi
-
-  # `src/lib/AST/BitcodeWriter.hpp` should define `void emitBlock(X const& I);`
-  # Look for the string `void emitBlock(${name}Info const& I);` in the file
-  # When looking for the string `void emitBlock(${name}Info const& I);` in the file,
-  # we need to use regex to account for the following:
-  # 1) Remove the leading and trailing spaces
-  # 2) Consecutive spaces should be replaced with a single space
-  # 3) Newlines should be removed
-  # 4) The variable name `I` can be anything
-  BITCODE_WRITE_REL_PATH="src/lib/AST/BitcodeWriter.hpp"
-  BITCODE_WRITE_PATH="$MRDOCS_ROOT/$BITCODE_WRITE_REL_PATH"
-  regex="void[[:space:]]+emitBlock[[:space:]]*\(${name}Info[[:space:]]*const[[:space:]]*&[[:space:]]*[a-zA-Z_][a-zA-Z0-9_]*[[:space:]]*\);"
-  if ! grep -Pzo "$regex" "$BITCODE_WRITE_PATH" > /dev/null; then
-    print_message_once "## ${name}Info"
-    print_message "The function \`void emitBlock(${name}Info const& I);\` is not defined in \`$BITCODE_WRITE_REL_PATH\`."
-  fi
-
   # `src/lib/Gen/xml/XMLWriter.cpp` should define `XMLWriter::writeX()`
   # Just look for the string `write$name` in this file
   if ! grep -q "write$name" "$MRDOCS_ROOT/src/lib/Gen/xml/XMLWriter.cpp"; then

docs/modules/ROOT/pages/contribute.adoc

@@ -105,7 +105,7 @@ include::partial$InfoNodes.inc[]
 `Info` can not only represent direct AST symbols but also {cpp} constructs that need to be inferred from these symbols.
 Nodes in the first category will typically be created in the initial extraction step, and nodes in the second category will be created in the finalization step.
 
-When defining a new `Info` type, it is important to consider how this type will be supported in all other modules of the codebase, including the AST visitor, the bitcode writer, generators, tests, and the documentation.
+When defining a new `Info` type, it is important to consider how this type will be supported in all other modules of the codebase, including the AST visitor, generators, tests, and the documentation.
 The script `.github/check_info_nodes_support.sh` will attempt to infer whether most of these features have been implemented for each node type.
 
 ==== Clang LibTooling
@@ -145,19 +145,13 @@ It is during this stage that USRs (universal symbol references) are generated an
 Except for built-in types, *all* entities referenced in the corpus will be traversed and be assigned a `SymbolID`; including those from the standard library.
 This is necessary to generate the full interface for user-defined types.
 
-==== Bitcode
-
-To maximize the size of the code base MrDocs is capable of processing, `Info`
-types generated during traversal are serialized to a compressed bitcode representation.
-
-The `ASTVisitor` reports each new `Info` object to the `BitcodeExecutionContext` (`src/lib/Lib/ExecutionContext.cpp`) which serializes it to the bitcode file.
-
 ==== Finalizing the Corpus
 
 After running the AST traversal on all translation units, `CorpusImpl::build` contains finalization steps for the `Corpus` object.
 At this point, we process C++ constructs that are not directly represented in the AST.
 
-The first finalization step happens in `BitcodeExecutionContext::reportEnd` (`src/lib/Lib/ExecutionContext.cpp`), where the `Info` objects with the same `SymbolID` are merged.
+The first finalization step happens in `CorpusImpl::build` (`src/lib/Lib/CorpusImpl.cpp`), where the `Info` objects from a single translation unit
+are merged into a map containing the merged results from all other TUs.
 The merging step is necessary as there may be multiple identical definitions of the same entity.
 For instance, this represents the case where a function is declared at different points in the code base and might have different attributes or comments.
 At this step, the doc comments are also finalized.

include/mrdocs/Metadata/Javadoc.hpp

@@ -90,11 +90,7 @@ using List = std::vector<std::unique_ptr<T>>;
     of the the doc comment specification.
 
     @note When a new tag is added, the `visit` function overloads
-    must be updated to handle the new tag. If the new object
-    contains new fields, `BitcodeWriter::emitBlock(doc::Node const& I)`
-    must include logic to serialize the new fields, and
-    `BitcodeReader::readBlock` must include logic to deserialize
-    the new fields.
+    must be updated to handle the new tag.
 
     @see https://en.wikipedia.org/wiki/Javadoc[Javadoc - Wikipedia]
     @see https://docs.oracle.com/javase/1.5.0/docs/tooldocs/solaris/javadoc.html[Javadoc Documentation]

src/lib/AST/ASTVisitor.cpp

@@ -12,7 +12,6 @@
 
 #include "ASTVisitor.hpp"
 #include "ASTVisitorHelpers.hpp"
-#include "Bitcode.hpp"
 #include "ParseJavadoc.hpp"
 #include "lib/Support/Path.hpp"
 #include "lib/Support/Debug.hpp"
@@ -163,17 +162,11 @@ static const Expr *SubstituteConstraintExpressionWithoutSatisfaction(
 //
 //------------------------------------------------
 
-/** Convert AST to our metadata and serialize to bitcode.
-
-    An instance of this object visits the AST
-    for exactly one translation unit. The AST is
-    extracted and converted into our metadata, and
-    this metadata is then serialized into bitcode.
-    The resulting bitcode is inserted into the tool
-    results, keyed by ID. Each ID can have multiple
-    serialized bitcodes, as the same declaration
-    in a particular include file can be seen by
-    more than one translation unit.
+/** Convert AST to metadata representation.
+
+    An instance of this object traverses the AST
+    for a translation unit and translate AST nodes
+    into our metadata.
 */
 class ASTVisitor
 {