Merge branch 'master' into nightly-ci

docs/contributing-book/src/code_docs/naming-components.md

@@ -26,11 +26,11 @@ Using a single character to name a variable conveys little to no information to
 
 - Is this a throw away variable?
 - What is the variable meant to represent where ever it is used?
-- Does it make sense to call it by the chosen character e.g. `x` when referring to forumlas?
+- Does it make sense to call it by the chosen character e.g. `x` when referring to formulas?
 
-### Ambigious Abbreviations
+### Ambiguous Abbreviations
 
-A common mistake is to abbreviate a variable when it does not need to be abbreviated or when the abbreviation may be ambigious.
+A common mistake is to abbreviate a variable when it does not need to be abbreviated or when the abbreviation may be ambiguous.
 
 For example, in the context of an industry that deals with temperature sensors what does the variable `temp` refer to?
 

docs/contributing-book/src/pull-requests/creating-pr.md

@@ -60,7 +60,7 @@ If there is an issue that the pull request is working off of then it's a good pr
 
 For example, issue number `123` would be referenced in the description as `closes #123`.
 
-Additionally, referencing the issue that the pull request is based on allows the reviewer to easily click on the link which will take them to the issue. This makes it easy to see the problem in detail and any discussion that occured.
+Additionally, referencing the issue that the pull request is based on allows the reviewer to easily click on the link which will take them to the issue. This makes it easy to see the problem in detail and any discussion that occurred.
 
 ### Merging the Pull Request
 

docs/contributing-book/src/pull-requests/index.md

@@ -1,6 +1,6 @@
 # Pull Requests
 
-A pull request is a term used to identify when a piece of work is ready to be pulled into and merged with another piece of work. This funtionality is especially useful when collaborating with others because it allows a review process to take place.
+A pull request is a term used to identify when a piece of work is ready to be pulled into and merged with another piece of work. This functionality is especially useful when collaborating with others because it allows a review process to take place.
 
 In order to create a high quality pull request there are a couple areas that need to be considered:
 

libs/src/reentrancy.sw

@@ -41,7 +41,7 @@ pub fn reentrancy_guard() {
 ///
 /// # Returns
 ///
-/// * [bool] - `true` if reentrancy pattern has occured.
+/// * [bool] - `true` if reentrancy pattern has occurred.
 ///
 /// # Examples
 ///
@@ -58,7 +58,7 @@ pub fn is_reentrant() -> bool {
     let this_id = ContractId::this();
 
     // Reentrancy cannot occur in an external context. If not detected by the time we get to the
-    // bottom of the call_frame stack, then no reentrancy has occured.
+    // bottom of the call_frame stack, then no reentrancy has occurred.
     let mut call_frame_pointer = frame_ptr();
     if !call_frame_pointer.is_null() {
         call_frame_pointer = get_previous_frame_pointer(call_frame_pointer);

libs/src/signed_integers/errors.sw

@@ -2,6 +2,6 @@ library;
 
 /// Error log for when unexpected behavior has occurred.
 pub enum Error {
-    /// Emitted when division by zero has occured.
+    /// Emitted when division by zero has occurred.
     ZeroDivisor: (),
 }