Convert CRLF to LF line ending

.gitattributes

@@ -0,0 +1,2 @@
+# Set the default behavior, in case people don't have core.autocrlf set.
+* text=auto

docs/methods/METHODS.md

@@ -60,8 +60,8 @@ A **use** is either :
 The analyzer reports unused exported public methods. The compiler does not
 report unused methods (private or public, exported or not, from a class, an
 immediate, or an object type), not instance vraiables. Thus, the 2 tools do not
-complement each other, and unused unexported methods or unused exported private
-methods remain undetected.
+complement each other, and unused unexported methods or unused exported private
+methods remain undetected.
 
 > [!WARNING]
 > Only a portion of the unused object-related code can be reported using the
@@ -80,7 +80,7 @@ constructs : warning 36.
 ### Warning 36: unused-ancestor
 
 This warning is disabled by default.
-It can be enabled by passing `-w +36` to the compiler.
+It can be enabled by passing `-w +36` to the compiler.
 
 Description:
 ```
@@ -133,10 +133,10 @@ The expected resolution for an unused exported public method is to remove it
 from the `.mli` if there is one and the `.ml`.
 
 > [!IMPORTANT]
-> Removing unused methods from the codebase may trigger the detection of new
-> unused methods and new unused values. Removing unused values may trigger the
-> detection of new unused methods or remove some in the case of values of
-> object types.
+> Removing unused methods from the codebase may trigger the detection of new
+> unused methods and new unused values. Removing unused values may trigger the
+> detection of new unused methods or remove some in the case of values of
+> object types.
 > Consequently, it is expected that a user might need to compile and analyze
 > their code multiple times when cleaning up their codebase.
 
@@ -145,7 +145,7 @@ from the `.mli` if there is one and the `.ml`.
 - The [code constructs](./code_constructs) directory contains a collection of
   examples dedicated to specific code constructs :
     - [Class](./code_constructs/CLASS.md)
-    - [Polymorphic class](./code_constructs/POLYMORPHIC_CLASS.md)
+    - [Polymorphic class](./code_constructs/POLYMORPHIC_CLASS.md)
     - [Constructor](./code_constructs/CONSTRUCTOR.md)
     - [Class type](./code_constructs/CLASS_TYPE.md)
     - [Inheritance](./code_constructs/INHERITANCE.md)

docs/methods/code_constructs/COERCION.md

@@ -50,11 +50,11 @@ let () =
 
 Before looking at the analysis results, let's look at the code.
 
-There is 1 object : `Coercion_lib.obj`, which defined 2 methods :
+There is 1 object : `Coercion_lib.obj`, which defined 2 methods :
 `used_by_requirement`, and `unused`. Neither of them is explicitly referenced,
 and the object is only manipulated through a coercion. The coercion produces an
 alias to `obj` named `_coerce`, which only exposes the method
-`used_by_requirement`. Because the method is required to exists in `obj` by the
+`used_by_requirement`. Because the method is required to exists in `obj` by the
 coercion, then the analyzer effectively considers it as used by requirement.
 
 Compile and analyze:
@@ -77,6 +77,6 @@ Nothing else to report in this section
 make: Leaving directory '/tmp/docs/methods/code_constructs/coercion'
 ```
 
-As expected, the analyzer reports `obj#unsed` as unused and not
+As expected, the analyzer reports `obj#unsed` as unused and not
 `obj#used_by_requirement`. The unused method can be removed from the `.mli` and
 the `.ml`. Our work here is done.

docs/methods/code_constructs/FACTORY_FUN.md

@@ -87,7 +87,7 @@ let () =
 Before looking at the analysis results, let's look at the code.
 
 The `Factory_fun_lib` declares and exports 1 factory function `get_stack` which
-takes `unit` as parameter and returns a fresh object. The returned object has
+takes `unit` as parameter and returns a fresh object. The returned object has
 4 methods, manipulating the unexported value `stack`.
 1 of these methods is used by requirement : `push`.
 2 of these methods are explicitly referenced : `peek`, and `pop`.

docs/methods/code_constructs/INHERITANCE.md

@@ -67,7 +67,7 @@ The code is pretty straightforward. `Inheritance_lib` defines 2 classes :
 
 CLass inheritance is semantically equivalent to module inclusion from the
 analyzer's point of view : the `parent` class is the actual "owner" of the
-methods, and `child` only re-exposes them. This has 2 consequences :
+methods, and `child` only re-exposes them. This has 2 consequences :
 - inherited methods in `child` are not analyzed individually;
 - using a method from `child` that is inherited from `parent` is the same as
   using the method from `parent`.

docs/methods/code_constructs/POLYMORPHIC_CLASS.md

@@ -70,7 +70,7 @@ let () =
 Before looking at the analysis results, let's look at the code.
 
 This example is very similar to the [Class](./CLASS.md) example, without the
-`unused_class` class. Instead of using an monomorphic `int_stack` class, the
+`unused_class` class. Instead of using an monomorphic `int_stack` class, the
 `Polymorphic_class_lib` defines a polymorphic `['a] stack` class.
 
 Methods `push`, `peek`, and `pop` are used, leaving `reset` as the only unused method.