diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..4cab1f4 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,2 @@ +# Set the default behavior, in case people don't have core.autocrlf set. +* text=auto diff --git a/docs/methods/METHODS.md b/docs/methods/METHODS.md index 90bb876..ed29ddd 100644 --- a/docs/methods/METHODS.md +++ b/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) diff --git a/docs/methods/code_constructs/COERCION.md b/docs/methods/code_constructs/COERCION.md index c494bc1..2c328f2 100644 --- a/docs/methods/code_constructs/COERCION.md +++ b/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. diff --git a/docs/methods/code_constructs/FACTORY_FUN.md b/docs/methods/code_constructs/FACTORY_FUN.md index 6fb67a4..76ad092 100644 --- a/docs/methods/code_constructs/FACTORY_FUN.md +++ b/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`. diff --git a/docs/methods/code_constructs/INHERITANCE.md b/docs/methods/code_constructs/INHERITANCE.md index 79e5efc..df2be48 100644 --- a/docs/methods/code_constructs/INHERITANCE.md +++ b/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`. diff --git a/docs/methods/code_constructs/POLYMORPHIC_CLASS.md b/docs/methods/code_constructs/POLYMORPHIC_CLASS.md index cbf5928..2b80023 100644 --- a/docs/methods/code_constructs/POLYMORPHIC_CLASS.md +++ b/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.