Merge branch 'balsoft/xrefcheck' into 'dev'

Check for invalid references in documentation on CI

See merge request ligolang/ligo!669

.gitlab-ci.yml

@@ -69,6 +69,17 @@ test:
     paths:
       - coverage
 
+xrefcheck:
+  extends: .nix
+  only:
+    - merge_requests
+  script:
+    # Should be replaced with
+    # nix run github:serokell/xrefcheck
+    # Once flakes roll out to stable
+    - nix run -f https://github.com/serokell/xrefcheck/archive/v0.1.1.2.tar.gz -c xrefcheck
+
+
 # Strange race conditions, disable for now
 .webide-e2e:
   extends: .nix

gitlab-pages/docs/contributors/documentation-and-releases.md

@@ -6,7 +6,7 @@ title: Documentation and releases
 
 ## Documentation
 
-If you'd like to contribute to the docs you can find them at [`gitlab-pages/docs`]() in raw markdown form.
+If you'd like to contribute to the docs you can find them at `gitlab-pages/docs` in raw markdown form.
 Deployment of the docs/website for LIGO is taken care of within the CI, from `dev` and `master` branches.
 
 ## Releases & versioning

gitlab-pages/docs/contributors/ligo_test_guide.md

@@ -102,7 +102,7 @@ What's going on is similar to the last program: `expect_eq_evaluate` runs a prog
 
 For example, once the program stops running the value of `address` is `"tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx"`. The *comparison*, however, is made to a constructed expression.  
 
-Remember that we're testing from OCaml, but the program is written and evaluated as LIGO. In order to provide a proper comparison, we convert our expected test values into LIGO expressions and data. Constructors such as `e_list` and `e_address` provide a bridge between LIGO and OCaml. Their definitions can be found in files such as [src/stages/ast_core/combinators.ml](https://gitlab.com/ligolang/ligo/blob/dev/src/stages/ast_core/combinators.ml), or using [Merlin's definition point finder](https://github.com/ocaml/merlin/wiki). These same functions are used during the simplification stage of LIGO compilation, so becoming familiar with them will help prepare you to work on the [front end](contributors/big-picture/front-end/).
+Remember that we're testing from OCaml, but the program is written and evaluated as LIGO. In order to provide a proper comparison, we convert our expected test values into LIGO expressions and data. Constructors such as `e_list` and `e_address` provide a bridge between LIGO and OCaml. Their definitions can be found in files such as [src/stages/ast_core/combinators.ml](https://gitlab.com/ligolang/ligo/blob/dev/src/stages/ast_core/combinators.ml), or using [Merlin's definition point finder](https://github.com/ocaml/merlin/wiki). These same functions are used during the simplification stage of LIGO compilation, so becoming familiar with them will help prepare you to work on the [front end](big-picture/front-end.md).
 
 ## How To Write A Test For LIGO
 

gitlab-pages/docs/language-basics/functions.md

@@ -127,7 +127,7 @@ in CameLIGO.  While this approach is faithful to the original OCaml,
 it is costlier in Michelson than naive function execution accepting
 multiple arguments. Instead, for most functions with more than one
 parameter, we should gather the arguments in a
-[tuple](language-basics/sets-lists-tuples.md) and pass the tuple in as
+[tuple](sets-lists-tuples.md) and pass the tuple in as
 a single parameter.
 
 Here is how you define a basic function that accepts two integers and

gitlab-pages/docs/language-basics/sets-lists-tuples.md

@@ -25,7 +25,7 @@ Like records, tuple components can be of arbitrary types.
 
 ### Defining Tuples
 
-Unlike [a record](language-basics/maps-records.md), tuple types do not
+Unlike [a record](maps-records.md), tuple types do not
 have to be defined before they can be used. However below we will give
 them names by *type aliasing*.
 
@@ -110,7 +110,7 @@ of the tuple.
 ### Accessing Components
 
 Accessing the components of a tuple in OCaml is achieved by
-[pattern matching](language-basics/unit-option-pattern-matching.md). LIGO
+[pattern matching](unit-option-pattern-matching.md). LIGO
 currently supports tuple patterns only in the parameters of functions,
 not in pattern matching. However, we can access components by their
 position in their tuple, which cannot be done in OCaml. *Tuple

gitlab-pages/docs/reference/big_map.md

@@ -11,7 +11,7 @@ import SyntaxTitle from '@theme/SyntaxTitle';
 A lazily deserialized map that's intended to store large amounts of data. 
 Lazily means that storage is read or written per key on demand. Therefore 
 there are no `map`, `fold`, and `iter` operations as in 
-[Map](./map-reference).
+[Map](map.md).
 
 The gas costs of big maps are higher than standard maps as data is lazily 
 deserialized.

gitlab-pages/docs/reference/list.md

@@ -143,7 +143,7 @@ val fold : ('accumulator -> 'item -> 'accumulator) -> 'item list -> 'accumulator
 let fold: ((('accumulator, 'item) => 'accumulator), list('item), 'accumulator) => 'accumulator
 </SyntaxTitle>
 
-[Fold over items in a list](../language-basics/sets-lists-tuples#folded-operation-over-lists);
+[Fold over items in a list](../language-basics/sets-lists-tuples.md#folded-operation-over-lists);
 
 <Syntax syntax="pascaligo">
 

gitlab-pages/docs/reference/set.md

@@ -248,7 +248,7 @@ val fold : ('accumulator -> 'item -> 'accumulator) -> 'set list -> 'accumulator
 let fold: ((('accumulator, 'item) => 'accumulator), set('item), 'accumulator) => 'accumulator
 </SyntaxTitle>
 
-[Fold over values in a set](../language-basics/sets-lists-tuples#folded-operation)
+[Fold over values in a set](../language-basics/sets-lists-tuples.md#folded-operation)
 
 
 <Syntax syntax="pascaligo">

gitlab-pages/docs/tutorials/get-started/tezos-taco-shop-payout.md

@@ -4,7 +4,7 @@ title: Paying out profits from the Taco Shop
 ---
 
 In the
-[previous tutorial](tutorials/get-started/tezos-taco-shop-smart-contract.md)
+[previous tutorial](tezos-taco-shop-smart-contract.md)
 we have learnt how to setup & interact with the LIGO CLI. Followed an
 implementation of a simple Taco Shop smart contract for our
 entrepreneur Pedro.

gitlab-pages/docs/tutorials/get-started/tezos-taco-shop-smart-contract.md

@@ -67,7 +67,7 @@ current_purchase_price = max_price / available_stock
 
 In this tutorial, we will use LIGO's dockerized version, for the sake
 of simplicity. You can find the installation instructions
-[here](intro/installation.md#dockerized-installation-recommended).
+[here](../../intro/installation.md#dockerized-installation-recommended).
 
 The best way to install the dockerized LIGO is as a **global
 executable** through the installation script, as shown in the
@@ -203,7 +203,7 @@ function main (const parameter : unit; const taco_shop_storage :  taco_shop_stor
 When dry-running a contract, it is crucial to provide a correct
 initial storage value.  In our case the storage is type-checked as
 `taco_shop_storage`. Reflecting
-[Pedro's daily offer](tutorials/get-started/tezos-taco-shop-smart-contract.md#daily-offer),
+[Pedro's daily offer](tezos-taco-shop-smart-contract.md#daily-offer),
 our storage's value will be defined as follows:
 
 **Storage value**
@@ -340,7 +340,7 @@ accessible within LIGO as `amount`.
 To make sure we get paid, we will:
 
 - calculate a `current_purchase_price` based on the
-  [equation specified earlier](tutorials/get-started/tezos-taco-shop-smart-contract.md#calculating-the-current-purchase-price)
+  [equation specified earlier](tezos-taco-shop-smart-contract.md#calculating-the-current-purchase-price)
 - check if the sent `amount` matches the `current_purchase_price`:
   - if not, then our contract will fail (`failwith`)
   - otherwise, stock for the given `taco_kind` will be decreased and