Merge branch 'master' into mergify/ggreif/config-update

.github/CODEOWNERS

@@ -1 +1 @@
-@dfinity/languages
+* @dfinity/languages

.github/repo_policies/BOT_APPROVED_FILES

@@ -0,0 +1,5 @@
+# List of approved files that can be changed by a bot via an automated PR
+
+Changelog.md
+doc/docusaurus/package-lock.json
+nix/sources.json

Changelog.md

@@ -1,5 +1,7 @@
 # Motoko compiler changelog
 
+## 0.13.5 (2024-12-06)
+
 * motoko (`moc`)
 
   * Breaking change (minor):
@@ -33,6 +35,19 @@
       On upgrade, the transient variable `invocations` will be reset to `0` and `value`, now implicitly `stable`, will retain its current value.
 
       Legacy actors and classes declared without the `persistent` keyword have the same semantics as before.
+
+  * Added new primitive `replyDeadline : () -> Nat64` to obtain when a response for a best-effort message is due (#4795).
+
+  * bugfix: fail-fast by limiting subtyping depth to avoid reliance on unpredictable stack overflow (#3057, #4798).
+
+* motoko-base
+
+  * Added `Text.fromList` and `Text.toList` functions (dfinity/motoko-base#676).
+
+  * Added `Text.fromArray/fromVarArray` functions (dfinity/motoko-base#674).
+
+  * Added `replyDeadline` to `ExperimentalInternetComputer` (dfinity/motoko-base⁠#677).
+
 ## 0.13.4 (2024-11-29)
 
 * motoko (`moc`)

doc/md/base/OrderedMap.md

@@ -19,7 +19,7 @@ Credits:
 The core of this implementation is derived from:
 
 * Ken Friis Larsen's [RedBlackMap.sml](https://github.com/kfl/mosml/blob/master/src/mosmllib/Redblackmap.sml), which itself is based on:
-* Stefan Kahrs, "Red-black trees with types", Journal of Functional Programming, 11(4): 425-432 (2001), [version 1 in web appendix](http://www.cs.ukc.ac.uk/people/staff/smk/redblack/rb.html).
+* Stefan Kahrs, "Red-black trees with types", Journal of Functional Programming, 11(4): 425-432 (2001), [version 1 in web appendix](https://www.cs.ukc.ac.uk/people/staff/smk/redblack/rb.html).
 
 ## Type `Map`
 ``` motoko no-repl

doc/md/base/OrderedSet.md

@@ -16,7 +16,7 @@ Credits:
 The core of this implementation is derived from:
 
 * Ken Friis Larsen's [RedBlackMap.sml](https://github.com/kfl/mosml/blob/master/src/mosmllib/Redblackmap.sml), which itself is based on:
-* Stefan Kahrs, "Red-black trees with types", Journal of Functional Programming, 11(4): 425-432 (2001), [version 1 in web appendix](http://www.cs.ukc.ac.uk/people/staff/smk/redblack/rb.html).
+* Stefan Kahrs, "Red-black trees with types", Journal of Functional Programming, 11(4): 425-432 (2001), [version 1 in web appendix](https://www.cs.ukc.ac.uk/people/staff/smk/redblack/rb.html).
 
 ## Type `Set`
 ``` motoko no-repl

doc/md/base/RBTree.md

@@ -38,7 +38,7 @@ Credits:
 The core of this implementation is derived from:
 
 * Ken Friis Larsen's [RedBlackMap.sml](https://github.com/kfl/mosml/blob/master/src/mosmllib/Redblackmap.sml), which itself is based on:
-* Stefan Kahrs, "Red-black trees with types", Journal of Functional Programming, 11(4): 425-432 (2001), [version 1 in web appendix](http://www.cs.ukc.ac.uk/people/staff/smk/redblack/rb.html).
+* Stefan Kahrs, "Red-black trees with types", Journal of Functional Programming, 11(4): 425-432 (2001), [version 1 in web appendix](https://www.cs.ukc.ac.uk/people/staff/smk/redblack/rb.html).
 
 ## Type `Color`
 ``` motoko no-repl

doc/md/canister-maintenance/compatibility.md

@@ -4,14 +4,14 @@ sidebar_position: 4
 
 # Verifying upgrade compatibility
 
-## Overview
+
 
 When upgrading a canister, it is important to verify that the upgrade can proceed without:
 
 -   Introducing an incompatible change in stable declarations.
 -   Breaking clients due to a Candid interface change.
 
-`dfx` checks these properties statically before attempting the upgrade. 
+`dfx` checks these properties statically before attempting the upgrade.
 Moreover, with [enhanced orthogonal persistence](orthogonal-persistence/enhanced.md), Motoko rejects incompatible changes of stable declarations.
 
 ## Upgrade example
@@ -233,14 +233,14 @@ cannot be consumed at new type
 
 Do you want to proceed? yes/No
 ```
-It is recommended not to continue, as you will lose the state in older versions of Motoko that use [classical orthogonal persistence](orthogonal-persistence/classical.md). 
+It is recommended not to continue, as you will lose the state in older versions of Motoko that use [classical orthogonal persistence](orthogonal-persistence/classical.md).
 Upgrading with [enhanced orthogonal persistence](orthogonal-persistence/enhanced.md) will trap and roll back, keeping the old state.
 
 Adding a new record field to the type of existing stable variable is not supported. The reason is simple: The upgrade would need to supply values for the new field out of thin air. In this example, the upgrade would need to conjure up some value for the `description` field of every existing `card` in `map`. Moreover, allowing adding optional fields is also a problem, as a record can be shared from various variables with different static types, some of them already declaring the added field or adding a same-named optional field with a potentially different type (and/or different semantics).
 
 ### Solution
 
-To resolve this issue, an [explicit](#explicit-migration) is needed:
+To resolve this issue, an [explicit migration](#explicit-migration) is needed:
 
 1. You must keep the old variable `map` with the same structural type. However, you are allowed to change type alias name (`Card` to `OldCard`).
 2. You can introduce a new variable `newMap` and copy the old state to the new one, initializing the new field as needed.
@@ -257,7 +257,6 @@ persistent actor {
     title : Text;
     description : Text;
   };
-
   var map : [(Nat32, OldCard)] = [];
   var newMap : [(Nat32, NewCard)] = Array.map<(Nat32, OldCard), (Nat32, NewCard)>(
     map,
@@ -278,7 +277,7 @@ persistent actor {
 };
 ```
 
-`dfx` will issue a warning that `map` will be dropped. 
+`dfx` will issue a warning that `map` will be dropped.
 
 Make sure, you have previously migrated the old state to `newMap` before applying this final reduced version.
 

doc/md/canister-maintenance/cycles.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 
 # Cycles
 
-## Overview
+
 
 Usage of a canister's resources on ICP is measured and paid for in [cycles](/docs/current/developer-docs/defi/cycles/converting_icp_tokens_into_cycles).
 

doc/md/canister-maintenance/optimization.md

@@ -4,14 +4,14 @@ sidebar_position: 2
 
 # Optimizing canisters
 
-## Overview
 
-The Motoko compiler produces small binaries with reasonably efficient code, but is not a highly optimized compiler. 
+
+The Motoko compiler produces small binaries with reasonably efficient code, but is not a highly optimized compiler.
 It is possible to further optimize Motoko binaries, both for code size and cycle usage, using additional tools such as `wasm-opt`.
 
 ## Using `wasm-opt`
 
-`Wasm-opt` is a general purpose Wasm optimizer that is now available in dfx, versions 0.14.0 and newer. 
+`Wasm-opt` is a general purpose Wasm optimizer that is now available in dfx, versions 0.14.0 and newer.
 
 `Wasm-opt` can be used to enable canister optimizations through a configuration option in the project's `dfx.json` file, such as:
 
@@ -27,9 +27,9 @@ It is possible to further optimize Motoko binaries, both for code size and cycle
 
 ### Optimization levels for cycle usage
 
-Using the `"optimize": "cycles"` option, you can expect a rough estimate of decreased cycles usage for Motoko canisters by around 10%. 
+Using the `"optimize": "cycles"` option, you can expect a rough estimate of decreased cycles usage for Motoko canisters by around 10%.
 
-The `"optimize": "cycles"` option is the recommended default, as it maps to optimization level 3 in the `wasm-opt` package. 
+The `"optimize": "cycles"` option is the recommended default, as it maps to optimization level 3 in the `wasm-opt` package.
 
 The optimization levels for cycles usage are as follows:
 
@@ -43,7 +43,7 @@ O0 (performs no optimizations)
 
 ### Optimization levels for binary size
 
-To optimize the binary size instead, you can use the `"optimize": "size"` option. By using the size option, binary sizes can be reduced by roughly 16%. 
+To optimize the binary size instead, you can use the `"optimize": "size"` option. By using the size option, binary sizes can be reduced by roughly 16%.
 
 The optimization levels for binary size are as follows:
 
@@ -52,7 +52,7 @@ Oz (equivalent to “size”)
 Os
 ```
 
-Each optimization preserves the Internet Computer specific metadata sections of each canister. 
+Each optimization preserves the Internet Computer specific metadata sections of each canister.
 
 :::info
 Note that in certain cases the optimizations can increase the complexity of certain functions in your Wasm module such that they are rejected by the replica. If you run into this issue, it is recommended to use a less aggressive optimization level such that you do not exceed the complexity limit.

doc/md/canister-maintenance/upgrades.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # Stable variables and upgrade methods
 
-## Overview
+
 
 One key feature of Motoko is its ability to automatically persist the program's state without explicit user instruction, called **orthogonal persistence**. This not only covers persistence across transactions but also includes canister upgrades. For this purpose, Motoko features a bespoke compiler and runtime system that manages upgrades in a sophisticated way such that a new program version can pick up the state left behind by a previous program version. As a result, Motoko data persistence is not simple but also prevents data corruption or loss, while being efficient at the same time. No database, stable memory API, or stable data structure is required to retain state across upgrades. Instead, a simple `stable` keyword is sufficient to declare an data structure of arbitrary shape persistent, even if the structure uses sharing, has a deep complexity, or contains cycles.
 
@@ -92,7 +92,6 @@ For example, the stable type `TemperatureSeries` covers the persistent data, whi
 ``` motoko no-repl file=../examples/WeatherActor.mo
 ```
 
-
 3. __Discouraged and not recommended__: [Pre- and post-upgrade hooks](#preupgrade-and-postupgrade-system-methods) allow copying non-stable types to stable types during upgrades. This approach is error-prone and does not scale for large data. **Per best practices, using these methods should be avoided if possible.** Conceptually, it also does not align well with the idea of orthogonal persistence.
 
 ## Stable type signatures
@@ -212,7 +211,7 @@ The following aspects are retained for historical reasons and backwards compatib
 Using the pre- and post-upgrade system methods is discouraged. It is error-prone and can render a canister unusable. In particular, if a `preupgrade` method traps and cannot be prevented from trapping by other means, then your canister may be left in a state in which it can no longer be upgraded.  Per best practices, using these methods should be avoided if possible.
 :::
 
-Motoko supports user-defined upgrade hooks that run immediately before and after an upgrade. These upgrade hooks allow triggering additional logic on upgrade. 
+Motoko supports user-defined upgrade hooks that run immediately before and after an upgrade. These upgrade hooks allow triggering additional logic on upgrade.
 These hooks are declared as `system` functions with special names, `preugrade` and `postupgrade`. Both functions must have type `: () → ()`.
 
 :::danger

doc/md/getting-started/basic-concepts.md

@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Basic concepts and terms
 
-## Overview
+
 
 Motoko is designed for distributed programming with **actors**. When programming on ICP in Motoko, each actor represents an ICP canister smart contract with a Candid interface.
 Within Motoko, the term actor is used to refer to any canister authored in any language that deploys to ICP. The role of Motoko is to make these actors easy to author and use programmatically once deployed.

doc/md/getting-started/dev-env.md

@@ -5,7 +5,7 @@ sidebar_position: 3
 
 # Developer environment
 
-## Overview
+
 
 To develop and deploy Motoko canister smart contracts, you will need a developer environment that contains the Motoko compiler and base library. It is recommended to use the [IC SDK](https://github.com/dfinity/sdk#readme), which includes Motoko, along with `dfx`, a command-line tool used to create, build, and deploy canisters on ICP.
 
@@ -54,14 +54,14 @@ Before you start developing Motoko, verify the following:
 
 ## Motoko version
 
-The following table details which version of Motoko shipped with each major version of the IC SDK. 
+The following table details which version of Motoko shipped with each major version of the IC SDK.
 
 | IC SDK version  | Motoko version   |
 |-----------------|------------------|
 | 0.20.0          | 0.11.1           |
 | 0.19.0          | 0.11.1           |
 | 0.18.0          | 0.11.0           |
-| 0.17.0          | 0.10.4           |  
+| 0.17.0          | 0.10.4           |
 | 0.16.0          | 0.10.4           |
 | 0.15.0          | 0.9.7            |
 | 0.14.0          | 0.8.7            |

doc/md/getting-started/examples.md

@@ -4,7 +4,7 @@ sidebar_position: 5
 
 # Sample projects and resources
 
-## Overview
+
 
 Want to get started building with Motoko? Check out some of these sample projects and Motoko resources to help you get started.
 

doc/md/getting-started/motoko-introduction.md

@@ -2,14 +2,28 @@
 sidebar_position: 1
 ---
 
-# Introduction
+# Meet Motoko: The language shaping the future of Web3
 
-## Overview
+<img src="https://github.com/user-attachments/assets/844ca364-4d71-42b3-aaec-4a6c3509ee2e" alt="Logo" width="150" height="150" />
 
 Motoko is a modern, general-purpose programming language you can use specifically to author ICP canister smart contracts. Although aimed primarily at ICP canister development, its design is general enough to support future compilation to other targets.
 
 Motoko is designed to be approachable for programmers who have some basic familiarity with object-oriented and/or functional programming idioms in either JavaScript, or another modern programming language, such as Rust, Swift, TypeScript, C#, or Java.
 
+
+```motoko
+// A simple Motoko smart contract.
+
+actor Main {
+  public query func hello() : async Text {
+    "Hello, world!"
+  };
+};
+
+await Main.hello();
+```
+
+
 Motoko provides:
 
 -   A high-level language for programming applications to run on ICP.
@@ -47,7 +61,7 @@ Its core is a call-by-value, impure functional language with imperative and obje
 
 Motoko is strongly typed and offers option types, records, variants, generics and subtyping. The type system is structural so that types with different names but equivalent definition are interchangeable; subtyping allows values to be used at their precise type but also at any more general supertype.
 
-- Motoko is safety-oriented. 
+- Motoko is safety-oriented.
 - Memory management is automated using a garbage collector.
 - Implicit null values are avoided. Nulls must be handled explicitly using option types.
 - The type system cannot be circumvented using unsafe casts.
@@ -93,6 +107,4 @@ Once upgraded, the new interface is compatible with the previous one, meaning ex
 
 ## Getting started
 
-Get started with Motoko by [setting up your developer environment](dev-env.md) and creating a simple [Hello, world!](quickstart.md) program.
-
-<img src="https://github.com/user-attachments/assets/844ca364-4d71-42b3-aaec-4a6c3509ee2e" alt="Logo" width="150" height="150" />
+Get started with Motoko by [setting up your developer environment](dev-env.md) and creating a simple [Hello, world!](quickstart.md) program.

doc/md/getting-started/quickstart.md

@@ -5,7 +5,7 @@ sidebar_position: 4
 
 # Motoko quickstart
 
-## Overview
+
 
 This quickstart guide showcases how to deploy a simple 'Hello, world!' Motoko smart contract.
 

doc/md/migration-guides/0.11.0-migration-guide.md

@@ -5,7 +5,7 @@ sidebar_position: 2
 
 # Motoko v0.11.0: Safety feature migration guide
 
-## Overview
+
 
 Motoko v0.11.0 and newer introduces a new safety feature that could cause breaking changes to existing code.
 

doc/md/migration-guides/overview.md

@@ -2,12 +2,10 @@
 sidebar_position: 1
 ---
 
-# Overview
+# Migration guides
 
 New versions of Motoko may introduce breaking changes that are not backwards compatible with older versions. In these scenarios, there are migration guides created to explain how to update your code to migrate to the new version properly. 
 
-## Migration guides
-
 - [0.11.0 Migration guide](0.11.0-migration-guide.md)
 
 <img src="https://github.com/user-attachments/assets/844ca364-4d71-42b3-aaec-4a6c3509ee2e" alt="Logo" width="150" height="150" />

doc/md/motoko-tools/embed-motoko.md

@@ -4,7 +4,7 @@ sidebar_position: 1
 
 # Embed Motoko
 
-## Overview
+
 
 The Embed Motoko tool enables Motoko smart contracts to be embedded in web pages such as a blog, web application, or even a Medium article. Simply insert your Motoko smart contract into the Embed Motoko tool and copy either the generated embedded URL or the HTML iframe to use in your web page.
 

doc/md/motoko-tools/mo-dev.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # Motoko dev server
 
-## Overview
+
 
 Motoko dev server, or `mo-dev` for short, is a command line tool that features a development server with live reloading for Motoko.
 
@@ -87,13 +87,13 @@ To configure the runtime of an individual unit test, include the following comme
 
 ## Examples
 
-The [Vite + React + Motoko](https://github.com/rvanasa/vite-react-motoko#readme) project showcases how to integrate `mo-dev` into a full-stack dapp. 
+The [Vite + React + Motoko](https://github.com/rvanasa/vite-react-motoko#readme) project showcases how to integrate `mo-dev` into a full-stack dapp.
 
 [![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/rvanasa/vite-react-motoko)
 
 ## Important notes
 
-`mo-dev` is early in development. Please feel free to report a bug, ask a question, or request a feature on the project's [GitHub issues](https://github.com/dfinity/motoko-dev-server/issues) page. 
+`mo-dev` is early in development. Please feel free to report a bug, ask a question, or request a feature on the project's [GitHub issues](https://github.com/dfinity/motoko-dev-server/issues) page.
 
 
 <img src="https://github.com/user-attachments/assets/844ca364-4d71-42b3-aaec-4a6c3509ee2e" alt="Logo" width="150" height="150" />

doc/md/motoko-tools/motoko-formatter.md

@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Motoko formatting tools
 
-## Overview
+
 
 The Motoko Prettier plugin can be used to format and validate Motoko source code files. It can be used through the [Prettier CLI](https://prettier.io/docs/en/cli.html) or through VS Code.