[libc][NFC] Fixing various typos

Author: gchatelet

libc/src/__support/libc_assert.h

@@ -49,7 +49,7 @@ LIBC_INLINE void report_assertion_failure(const char *assertion,
 #endif
 
 // The public "assert" macro calls abort on failure. Should it be same here?
-// The libc intenral assert can fire from anywhere inside the libc. So, to
+// The libc internal assert can fire from anywhere inside the libc. So, to
 // avoid potential chicken-and-egg problems, it is simple to do a quick_exit
 // on assertion failure instead of calling abort. We also don't want to use
 // __builtin_trap as it could potentially be implemented using illegal

libc/test/UnitTest/LibcTest.h

@@ -36,7 +36,7 @@ namespace __llvm_libc {
 namespace testing {
 
 // Only the following conditions are supported. Notice that we do not have
-// a TRUE or FALSE condition. That is because, C library funtions do not
+// a TRUE or FALSE condition. That is because, C library functions do not
 // return boolean values, but use integral return values to indicate true or
 // false conditions. Hence, it is more appropriate to use the other comparison
 // conditions for such cases.

libc/test/UnitTest/Test.h

@@ -16,7 +16,7 @@
 // redefine it as necessary.
 #define libc_make_test_file_path(file_name) (file_name)
 
-#ifdef LIBC_COPT_TEST_USE_FUCHSIA
+#if defined(LIBC_COPT_TEST_USE_FUCHSIA)
 #include "FuchsiaTest.h"
 #elif defined(LIBC_COPT_TEST_USE_PIGWEED)
 #include "PigweedTest.h"

libc/test/src/string/memory_utils/memory_check_utils.h

@@ -10,7 +10,7 @@
 #define LIBC_TEST_SRC_STRING_MEMORY_UTILS_MEMORY_CHECK_UTILS_H
 
 #include "src/__support/CPP/span.h"
-#include "src/__support/libc_assert.h"
+#include "src/__support/libc_assert.h" // LIBC_ASSERT
 #include "src/__support/macros/sanitizer.h"
 #include "src/string/memory_utils/utils.h"
 #include <stddef.h> // size_t

libc/utils/MPFRWrapper/MPFRUtils.h

@@ -197,8 +197,8 @@ class MPFRMatcher : public testing::Matcher<OutputType> {
     return match(input, match_value);
   }
 
-  // This method is marked with NOLINT because it the name `explainError`
-  // does not confirm to the coding style.
+  // This method is marked with NOLINT because the name `explainError` does not
+  // conform to the coding style.
   void explainError() override { // NOLINT
     explain_error(input, match_value);
   }