Merge branch 'master' into patch-1

CppCoreGuidelines.md

@@ -4492,7 +4492,7 @@ Destructor rules:
 * [C.30: Define a destructor if a class needs an explicit action at object destruction](#Rc-dtor)
 * [C.31: All resources acquired by a class must be released by the class's destructor](#Rc-dtor-release)
 * [C.32: If a class has a raw pointer (`T*`) or reference (`T&`), consider whether it might be owning](#Rc-dtor-ptr)
-* [C.33: If a class has an owning pointer member, define or `=delete` a destructor](#Rc-dtor-ptr2)
+* [C.33: If a class has an owning pointer member, define a destructor](#Rc-dtor-ptr2)
 * [C.35: A base class destructor should be either public and virtual, or protected and non-virtual](#Rc-dtor-virtual)
 * [C.36: A destructor may not fail](#Rc-dtor-fail)
 * [C.37: Make destructors `noexcept`](#Rc-dtor-noexcept)
@@ -14972,7 +14972,6 @@ There is no explicit locking and both correct (value) return and error (exceptio
         return value;
     }
 
-
     void async_example()
     {
         try
@@ -19200,6 +19199,7 @@ Nevertheless, the guidance is to use the quoted form for including files that ex
     #include "foo_utils/utils.h"     // A file locally relative to foo.cpp, use "" form
 
 ##### Note
+
 Failing to follow this results in difficult to diagnose errors due to picking up the wrong file by incorrectly specifying the scope when it is included. For example, in a typical case where the `#include ""` search algorithm may search for a file existing at a local relative path first, then using this form to refer to a file that is not locally relative could mean that if a file ever comes into existence at the local relative path (e.g. the including file is moved to a new location), it will now be found ahead of the previous include file and the set of includes will have been changed in an unexpected way.
 
 Library creators should put their headers in a folder and have clients include those files using the relative path `#include <some_library/common.h>`
@@ -20281,9 +20281,11 @@ and errors (when we didn't deal correctly with semi-constructed objects consiste
         // main problem: constructor does not fully construct
         Picture(int x, int y)
         {
-            mx = x;         // also bad: assignment in constructor body rather than in member initializer
+            mx = x;         // also bad: assignment in constructor body
+                            // rather than in member initializer
             my = y;
-            data = nullptr; // also bad: constant initialization in constructor rather than in member initializer
+            data = nullptr; // also bad: constant initialization in constructor
+                            // rather than in member initializer
         }
 
         ~Picture()
@@ -20465,7 +20467,7 @@ Reference sections:
   Libraries used have to have been approved for mission critical applications.
   Any similarities to this set of guidelines are unsurprising because Bjarne Stroustrup was an author of JSF++.
   Recommended, but note its very specific focus.
-* [_MISRA C++ 2008: Guidelines for the use of the C++ language in critical systems_] (https://www.misra.org.uk/Buyonline/tabid/58/Default.aspx).
+* [MISRA C++ 2008: Guidelines for the use of the C++ language in critical systems](https://www.misra.org.uk/Buyonline/tabid/58/Default.aspx).
 * [Mozilla Portability Guide](https://developer.mozilla.org/en-US/docs/Mozilla/C%2B%2B_Portability_Guide).
   As the name indicates, this aims for portability across many (old) compilers.
   As such, it is restrictive.

scripts/hunspell/isocpp.dic

@@ -52,6 +52,7 @@ ASIC
 asio
 AST
 async
+AUTOSAR
 'B'
 b2
 BDE
@@ -320,6 +321,7 @@ Meyers96
 Meyers97
 microbenchmarks
 middleware
+MISRA
 mixin
 mixins
 mnemonizes
@@ -598,6 +600,7 @@ UTF
 util
 v's
 v1
+v17
 v2
 va
 ValueType