refactor: Address some issues with enums and overhaul documentation (#2974)

Author: narendasan

Diff for: .pre-commit-config.yaml

@@ -51,6 +51,10 @@ repos:
     hooks:
       - id: black
         exclude: ^examples/custom_converters/elu_converter/setup.py|^docs
+  - repo: https://github.com/crate-ci/typos
+    rev: v1.22.9
+    hooks:
+      - id: typos
   - repo: local
     hooks:
     -   id: dont-commit-upstream

Diff for: CODE_OF_CONDUCT.md

@@ -6,7 +6,7 @@ In the interest of fostering an open and welcoming environment, we as
 contributors and maintainers pledge to make participation in our project and
 our community a harassment-free experience for everyone, regardless of age, body
 size, disability, ethnicity, sex characteristics, gender identity and expression,
-level of experience, education, socio-economic status, nationality, personal
+level of experience, education, socioeconomic status, nationality, personal
 appearance, race, religion, or sexual identity and orientation.
 
 ## Our Standards

Diff for: CONTRIBUTING.md

@@ -4,9 +4,9 @@
 
 Do try to fill an issue with your feature or bug before filling a PR (op support is generally an exception as long as you provide tests to prove functionality). There is also a backlog (https://github.com/pytorch/TensorRT/issues) of issues which are tagged with the area of focus, a coarse priority level and whether the issue may be accessible to new contributors. Let us know if you are interested in working on a issue. We are happy to provide guidance and mentorship for new contributors. Though note, there is no claiming of issues, we prefer getting working code quickly vs. addressing concerns about "wasted work".
 
-#### Development enviornment
+#### Development environment
 
-Our build system relies on `bazel` (https://bazel.build/). Though there are many ways to install `bazel`, the prefered method is to use `bazelisk` (https://github.com/bazelbuild/bazelisk) which makes it simple to set up the correct version of bazel on the fly. Additional developement dependencies can be installed via the `requirements-dev.txt` file.
+Our build system relies on `bazel` (https://bazel.build/). Though there are many ways to install `bazel`, the preferred method is to use `bazelisk` (https://github.com/bazelbuild/bazelisk) which makes it simple to set up the correct version of bazel on the fly. Additional development dependencies can be installed via the `requirements-dev.txt` file.
 
 #### Communication
 
@@ -27,7 +27,7 @@ We use the PyTorch Slack for communication about core development, integration w
 
 - Avoid introducing unnecessary complexity into existing code so that maintainability and readability are preserved
 
-- Try to avoid commiting commented out code
+- Try to avoid committing commented out code
 
 - Minimize warnings (and no errors) from the compiler
 

Diff for: cmake/paths.cmake

@@ -6,7 +6,7 @@ set(ARCHIVE_OUTPUT_DIRECTORY "lib")
 set(RUNTIME_OUTPUT_DIRECTORY "bin")
 set(HEADERS_OUTPUT_DIRECTORY "include")
 
-#Set target ouput directory in the build directory
+#Set target output directory in the build directory
 set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${ARCHIVE_OUTPUT_DIRECTORY}")
 set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${LIBRARY_OUTPUT_DIRECTORY}")
 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/${RUNTIME_OUTPUT_DIRECTORY}")

Diff for: dev_dep_versions.yml

@@ -1,3 +1,2 @@
-__version__: "2.5.0.dev0"
 __cuda_version__: "12.4"
 __tensorrt_version__: "10.0.1"

Diff for: docker/Dockerfile

@@ -50,7 +50,7 @@ RUN TENSORRT_MAJOR_VERSION=`echo ${TENSORRT_VERSION} | cut -d '.' -f 1` && \
 RUN wget -q https://github.com/bazelbuild/bazelisk/releases/download/v1.17.0/bazelisk-linux-amd64 -O /usr/bin/bazel &&\
     chmod a+x /usr/bin/bazel
 
-# Build Torch-TensorRT in an auxillary container
+# Build Torch-TensorRT in an auxiliary container
 FROM base as torch-tensorrt-builder-base
 
 ARG ARCH="x86_64"

Diff for: docker/README.md

@@ -35,7 +35,7 @@ nvidia-docker run --gpus all -it --shm-size=8gb --env="DISPLAY" --volume="/tmp/.
 Test:
 
 
-You can run any converter test to verify if Torch-TRT built sucessfully inside the container. Once you launch the container, you can run
+You can run any converter test to verify if Torch-TRT built successfully inside the container. Once you launch the container, you can run
 ```
 bazel test //tests/core/conversion/converters:test_activation --compilation_mode=opt --test_output=summary --config use_precompiled_torchtrt --config pre_cxx11_abi
 ```

Diff for: docsrc/RELEASE_CHECKLIST.md

@@ -9,7 +9,7 @@ While Torch-TensorRT is in alpha, patch versions are bumped sequentially on brea
 In beta Torch-TensorRT will get a minor version bump on breaking changes, or upgrade to the next version of PyTorch, patch version will be incremented based on significant bug fixes, or siginficant new functionality in the compiler.
 
 Once Torch-TensorRT hits version 1.0.0, major versions are bumped on breaking API changes, breaking changes or significant new functionality in the compiler
-will result in a minor version bump and sigificant bug fixes will result in a patch version change.
+will result in a minor version bump and significant bug fixes will result in a patch version change.
 
 ## Steps to Packaging a Release
 
@@ -50,7 +50,7 @@ will result in a minor version bump and sigificant bug fixes will result in a pa
             - `[3, 1920, 1080]` (P2)
     - Batch Sizes: 1, 4, 8, 16, 32
     - Frameworks: PyTorch, Torch-TensorRT, ONNX + TRT
-        - If any models do not convert to ONNX / TRT, that is fine. Mark them as failling / no result
+        - If any models do not convert to ONNX / TRT, that is fine. Mark them as failing / no result
     - Devices:
         - A100 (P0)
         - A30 / A30 MIG (P1) (same batches as T4

Diff for: docsrc/conf.py

@@ -25,7 +25,7 @@
 # -- Project information -----------------------------------------------------
 
 project = "Torch-TensorRT"
-copyright = "2022, NVIDIA Corporation"
+copyright = "2024, NVIDIA Corporation"
 author = "NVIDIA Corporation"
 
 version = f"v{torch_tensorrt.__version__}"
@@ -151,6 +151,9 @@
     "master_doc": True,
     "version_info": {
         "main": "https://pytorch.org/TensorRT/",
+        "v2.3.0": "https://pytorch.org/TensorRT/v2.3.0",
+        "v2.2.0": "https://pytorch.org/TensorRT/v2.2.0",
+        "v2.1.0": "https://pytorch.org/TensorRT/v2.1.0",
         "v1.4.0": "https://pytorch.org/TensorRT/v1.4.0",
         "v1.3.0": "https://pytorch.org/TensorRT/v1.3.0",
         "v1.2.0": "https://pytorch.org/TensorRT/v1.2.0",
@@ -186,6 +189,8 @@
 
 nbsphinx_execute = "never"
 
+autodoc_member_order = "groupwise"
+
 # -- A patch that prevents Sphinx from cross-referencing ivar tags -------
 # See http://stackoverflow.com/a/41184353/3343043
 

Diff for: docsrc/contributors/conversion.rst

@@ -3,7 +3,7 @@
 Conversion Phase
 ==================
 
-Once the graph has be simplified to a form thats easy to convert, we then set up a conversion context
+Once the graph has be simplified to a form that's easy to convert, we then set up a conversion context
 to manage the construction of a TensorRT ``INetworkDefinition`` from the blocks nodes. The conversion context
 records the set of converted nodes, block inputs and outputs and other information about the conversion
 of the graph. This data is then used to help converters link together layers and also hold build time

Diff for: docsrc/contributors/dynamo_converters.rst

@@ -36,7 +36,7 @@ The decorator takes a number of arguments:
 All that is required for a converter is the key.
 
 The function body is responsible for taking the current state of the network and adding the next subgraph to perform the op specified in the decorator with TensorRT operations.
-The function is provided arguments as the native PyTorch op would be provided with the added case of numpy arrays for frozen Tensor attributes or TensorRT ITensors which are ouput Tensors of previous nodes, correspoding to edges/output Tensors of intermediate operations in the graph.
+The function is provided arguments as the native PyTorch op would be provided with the added case of numpy arrays for frozen Tensor attributes or TensorRT ITensors which are output Tensors of previous nodes, corresponding to edges/output Tensors of intermediate operations in the graph.
 To determine the types expected as well as the return type of the converter, look at the definition of the op being converted. In the case of ``aten`` operations, this file will be the source of truth: https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/native/native_functions.yaml
 Since many converters a developer may write are a composition of lower level operators, instead of needing to implement the converter in raw TensorRT, the ``torch_tensorrt.dynamo.conversion.impl`` subpackage contains many implementations of operations that can be chained to create a TensorRT subgraph.
 
@@ -53,14 +53,14 @@ Capability Validation
 
 There are some converters which have special cases to be accounted for. In those cases, one should use ``capability_validators`` to register the converter using ``@dynamo_tensorrt_converter``
 We illustrate this through ``torch.ops.aten.embedding.default``. It has parameters - ``scale_grad_by_freq`` and ``sparse`` which are not currently supported by the implementation.
-In such cases we can write validator ``embedding_param_validator`` which implements that given those paramters the converter is not supported and register the converter by
+In such cases we can write validator ``embedding_param_validator`` which implements that given those parameters the converter is not supported and register the converter by
 
 
 Type Contract
 ^^^^^^^^^^^^^^^
 
 The function is expected to follow the type contract established by the signature. This includes accepting the union of valid PyTorch types + numpy arrays for constant tensors and TensorRT ITensors.
-In the case that only a subset of types is supported in the converter, you can also add the ``torch_tensorrt.dynamo.conversion.converter_utils.enforce_tensor_types``, which allows you to specify a dictionary mapping between input positions and types that those inputs can take. Where possible the decorator will convert inputs to match these types prefering the order provided.
+In the case that only a subset of types is supported in the converter, you can also add the ``torch_tensorrt.dynamo.conversion.converter_utils.enforce_tensor_types``, which allows you to specify a dictionary mapping between input positions and types that those inputs can take. Where possible the decorator will convert inputs to match these types preferring the order provided.
 ``int`` keys in the dictionary will refer to positional arguments in ``args``. ``str`` keys will refer to keyword arguments in ``kwargs``.
 
 
@@ -105,7 +105,7 @@ Some operations do not produce TensorRT subgraphs as a side-effect. These are te
 Operator Decomposition
 -----------------------
 
-There are some converters which can be decomposed into suboperations in PyTorch and need not have seperate converter registration.
+There are some converters which can be decomposed into suboperations in PyTorch and need not have separate converter registration.
 Such converters can be implemented via a decomposition
 
 Example: ``addmm``

Diff for: docsrc/contributors/lowering.rst

@@ -30,12 +30,12 @@ Eliminate Dead Code
 
 Dead code elimination will check if a node has side effects and not delete it if it does.
 
-Eliminate Exeception Or Pass Pattern
+Eliminate Exception Or Pass Pattern
 ***************************************
 
     `Torch-TensorRT/core/lowering/passes/exception_elimination.cpp <https://github.com/pytorch/TensorRT/blob/master/core/lowering/passes/exception_elimination.cpp>`_
 
-A common pattern in scripted modules are dimension gaurds which will throw execptions if
+A common pattern in scripted modules are dimension guards which will throw exceptions if
 the input dimension is not what was expected.
 
 .. code-block:: none
@@ -48,9 +48,9 @@ the input dimension is not what was expected.
         block1():
         -> ()
 
-Since we are resolving all of this at compile time and there are no execptions in the TensorRT graph, we just remove it.
+Since we are resolving all of this at compile time and there are no exceptions in the TensorRT graph, we just remove it.
 
-Eliminate Redundant Gaurds
+Eliminate Redundant Guards
 ***************************************
 
     `torch/csrc/jit/passes/guard_elimination.h <https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/guard_elimination.h>`_
@@ -63,15 +63,15 @@ Freeze Module
 
     `torch/csrc/jit/passes/freeze_module.h <https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/freeze_module.h>`_
 
-Freeze attributes and inline constants and modules. Propogates constants in the graph.
+Freeze attributes and inline constants and modules. Propagates constants in the graph.
 
 Fuse AddMM Branches
 ***************************************
 
     `Torch-TensorRT/core/lowering/passes/fuse_addmm_branches.cpp <https://github.com/pytorch/TensorRT/blob/master/core/lowering/passes/fuse_addmm_branches.cpp>`_
 
 A common pattern in scripted modules is tensors of different dimensions use different constructions for implementing linear layers. We fuse these
-different varients into a single one that will get caught by the Unpack AddMM pass.
+different variants into a single one that will get caught by the Unpack AddMM pass.
 
 .. code-block:: none
 
@@ -103,7 +103,7 @@ Fuse Flatten Linear
 
     `Torch-TensorRT/core/lowering/passes/fuse_flatten_linear.cpp <https://github.com/pytorch/TensorRT/blob/master/core/lowering/passes/fuse_flatten_linear.cpp>`_
 
-TensorRT implicity flattens input layers into fully connected layers when they are higher than 1D. So when there is a
+TensorRT implicitly flattens input layers into fully connected layers when they are higher than 1D. So when there is a
 ``aten::flatten`` -> ``aten::linear`` pattern we remove the ``aten::flatten``.
 
 Lower Graph
@@ -147,7 +147,7 @@ Places delimiting nodes around module calls pre freezing to signify where in the
 
 Looks for delimiters then marks all nodes between the delimiters to tell partitioning to run them in PyTorch
 
-Peephole Optimze
+Peephole Optimize
 ***************************************
 
     `torch/csrc/jit/passes/peephole_optimze.h <https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/ppeephole_optimze.h>`_
@@ -179,7 +179,7 @@ Remove To
 
     `Torch-TensorRT/core/lowering/passes/remove_to.cpp <https://github.com/pytorch/TensorRT/blob/master/core/lowering/passes/remove_to.cpp>`_
 
-Removes ``aten::to`` operators that do casting, since TensorRT mangages it itself. It is important that this is one of the last passes run so that
+Removes ``aten::to`` operators that do casting, since TensorRT manages it itself. It is important that this is one of the last passes run so that
 other passes have a change to move required cast operators out of the main namespace.
 
 Unpack AddMM
@@ -204,7 +204,7 @@ Unroll Loops
 
     `torch/csrc/jit/passes/loop_unrolling.h <https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/loop_unrolling.h>`_
 
-Unrolls the operations of compatable loops (e.g. sufficently short) so that you only have to go through the loop once.
+Unrolls the operations of compatible loops (e.g. sufficiently short) so that you only have to go through the loop once.
 
 Replace Tile with Repeat
 ***************************************

Diff for: docsrc/contributors/runtime.rst

@@ -6,9 +6,9 @@ Runtime Phase
 The Runtime phase is responsible for constructing self standing TorchScript graphs with embedded TensorRT engines and serving as the runtime
 when these engines are called. The main interface accepts a serialized TensorRT engine. The execution phase
 will deserialize and wrap this engine in a class which maintains a execution context for each engine
-and some metadata about its inputs and outputs and is compatable with the TorchScript interpreter so that
+and some metadata about its inputs and outputs and is compatible with the TorchScript interpreter so that
 it can be moved around and used like other TorchScript IValues. The engine is run by providing it and inputs
-to the ``tensorrt::execute_engine`` operator which will take the engine and its inputs and return the results of engine exeuction.
+to the ``tensorrt::execute_engine`` operator which will take the engine and its inputs and return the results of engine execution.
 
 
 Background

Diff for: docsrc/dynamo/dynamo_export.rst

@@ -27,7 +27,7 @@ usage of the dynamo frontend
 
 .. note::  ``torch_tensorrt.dynamo.compile`` is the main API for users to interact with Torch-TensorRT dynamo frontend. The input type of the model should be ``ExportedProgram`` (ideally the output of ``torch.export.export`` or ``torch_tensorrt.dynamo.trace`` (discussed in the section below)) and output type is a ``torch.fx.GraphModule`` object.
 
-Customizeable Settings
+Customizable Settings
 ----------------------
 
 There are lot of options for users to customize their settings for optimizing with TensorRT.

Diff for: docsrc/dynamo/torch_compile.rst

@@ -26,7 +26,7 @@ The primary goal of the Torch-TensorRT `torch.compile` backend is to enable Just
 
 The backend can handle a variety of challenging model structures and offers a simple-to-use interface for effective acceleration of models. Additionally, it has many customization options to ensure the compilation process is fitting to the specific use case.
 
-Customizeable Settings
+Customizable Settings
 -----------------
 .. autoclass:: CompilationSettings
 
@@ -87,7 +87,7 @@ If key operators for your model are unsupported, see :ref:`dynamo_conversion` to
 
 Feasibility of Serialization
 ^^^^^^^^^^^^^^^^^
-Compilation can also be helpful in demonstrating graph breaks and the feasibility of serialization of a particular model. For instance, if a model has no graph breaks and compiles successfully with the Torch-TensorRT backend, then that model should be compileable and serializeable via the `torch_tensorrt` Dynamo IR, as discussed in :ref:`dynamic_shapes`. To determine the number of graph breaks in a model, the `torch._dynamo.explain` function is very useful:
+Compilation can also be helpful in demonstrating graph breaks and the feasibility of serialization of a particular model. For instance, if a model has no graph breaks and compiles successfully with the Torch-TensorRT backend, then that model should be compilable and serializeable via the `torch_tensorrt` Dynamo IR, as discussed in :ref:`dynamic_shapes`. To determine the number of graph breaks in a model, the `torch._dynamo.explain` function is very useful:
 
 .. code-block:: python