Merge pull request #44228 from JuliaLang/sk/nbsp

- replace non-breaking spaces with plain spaces
- use only UNIX line endings (\n)
- end text files with single newlines
- rewrite whitespace checks in Julia & check for:
  - trailing non-ASCII whitespace
  - non-breaking spaces anywhere
  - non-UNIX line endings
  - missing trailing newline

Author: StefanKarpinski

.mailmap

@@ -282,4 +282,4 @@ Daniel Karrasch <[email protected]> <[email protected]>
 Daniel Karrasch <[email protected]> <[email protected]>
 
 Roger Luo <[email protected]> <[email protected]>
-Roger Luo <[email protected]> <[email protected]>
+Roger Luo <[email protected]> <[email protected]>

HISTORY.md

@@ -4102,7 +4102,7 @@ Library improvements
 
     + Using colons (`:`) to represent a collection of indices is deprecated. They now must be
       explicitly converted to a specialized array of integers with the `to_indices` function.
-      As a result, the type of `SubArray`s that represent views over colon indices has changed.
+      As a result, the type of `SubArray`s that represent views over colon indices has changed.
 
     + Logical indexing is now more efficient. Logical arrays are converted by `to_indices` to
       a lazy, iterable collection of indices that doesn't support indexing. A deprecation

Makefile

@@ -99,7 +99,7 @@ docs-revise:
 
 check-whitespace:
 ifneq ($(NO_GIT), 1)
-	@$(JULIAHOME)/contrib/check-whitespace.sh
+	@$(JULIAHOME)/contrib/check-whitespace.jl
 else
 	$(warn "Skipping whitespace check because git is unavailable")
 endif
@@ -472,7 +472,7 @@ endif
 
 	# Include all git-tracked filenames
 	git ls-files >> light-source-dist.tmp
-	
+
 	# Include documentation filenames
 	find doc/_build/html >> light-source-dist.tmp
 

base/abstractset.jl

@@ -434,7 +434,7 @@ issetequal(a::AbstractSet, b) = issetequal(a, Set(b))
 function issetequal(a, b::AbstractSet)
     if haslength(a)
         # check b for too many unique elements
-        length(a) < length(b) && return false
+        length(a) < length(b) && return false
     end
     return issetequal(Set(a), b)
 end

base/array.jl

@@ -452,7 +452,7 @@ the `value` that was passed; this means that if the `value` is itself modified,
 all elements of the `fill`ed array will reflect that modification because they're
 _still_ that very `value`. This is of no concern with `fill(1.0, (5,5))` as the
 `value` `1.0` is immutable and cannot itself be modified, but can be unexpected
-with mutable values like — most commonly — arrays.  For example, `fill([], 3)`
+with mutable values like — most commonly — arrays.  For example, `fill([], 3)`
 places _the very same_ empty array in all three locations of the returned vector:
 
 ```jldoctest

base/gmp.jl

@@ -736,7 +736,7 @@ function digits!(a::AbstractVector{T}, n::BigInt; base::Integer = 10) where {T<:
         i, j = firstindex(a)-1, length(s)+1
         lasti = min(lastindex(a), firstindex(a) + length(s)-1 - isneg(n))
         while i < lasti
-            # base ≤ 36: 0-9, plus a-z for 10-35
+            # base ≤ 36: 0-9, plus a-z for 10-35
             # base > 36: 0-9, plus A-Z for 10-35 and a-z for 36..61
             x = s[j -= 1]
             a[i += 1] = base ≤ 36 ? (x>0x39 ? x-0x57 : x-0x30) : (x>0x39 ? (x>0x60 ? x-0x3d : x-0x37) : x-0x30)

base/indices.jl

@@ -23,11 +23,11 @@ A linear indexing style uses one integer index to describe the position in the a
 (even if it's a multidimensional array) and column-major
 ordering is used to efficiently access the elements. This means that
 requesting [`eachindex`](@ref) from an array that is `IndexLinear` will return
-a simple one-dimensional range, even if it is multidimensional.
+a simple one-dimensional range, even if it is multidimensional.
 
 A custom array that reports its `IndexStyle` as `IndexLinear` only needs
 to implement indexing (and indexed assignment) with a single `Int` index;
-all other indexing expressions — including multidimensional accesses — will
+all other indexing expressions — including multidimensional accesses — will
 be recomputed to the linear index.  For example, if `A` were a `2×3` custom
 matrix with linear indexing, and we referenced `A[1, 3]`, this would be
 recomputed to the equivalent linear index and call `A[5]` since `2*1 + 3 = 5`.
@@ -50,13 +50,13 @@ a range of [`CartesianIndices`](@ref).
 
 A `N`-dimensional custom array that reports its `IndexStyle` as `IndexCartesian` needs
 to implement indexing (and indexed assignment) with exactly `N` `Int` indices;
-all other indexing expressions — including linear indexing — will
+all other indexing expressions — including linear indexing — will
 be recomputed to the equivalent Cartesian location.  For example, if `A` were a `2×3` custom
 matrix with cartesian indexing, and we referenced `A[5]`, this would be
 recomputed to the equivalent Cartesian index and call `A[1, 3]` since `5 = 2*1 + 3`.
 
 It is significantly more expensive to compute Cartesian indices from a linear index than it is
-to go the other way.  The former operation requires division — a very costly operation — whereas
+to go the other way.  The former operation requires division — a very costly operation — whereas
 the latter only uses multiplication and addition and is essentially free. This asymmetry means it
 is far more costly to use linear indexing with an `IndexCartesian` array than it is to use
 Cartesian indexing with an `IndexLinear` array.

base/missing.jl

@@ -463,4 +463,3 @@ macro coalesce(args...)
     end
     return esc(:(let val; $expr; end))
 end
-

base/pkgid.jl

@@ -42,4 +42,3 @@ function binunpack(s::String)
     name = read(io, String)
     return PkgId(UUID(uuid), name)
 end
-

base/randomdevice.jl

@@ -74,4 +74,4 @@ function _make_uint_seed()
     catch
         return _ad_hoc_entropy() % Cuint
     end
-end
+end