Use julia-repl in documentation

With the highlighting updates in Documenter v0.10.1 it is now possible
to have specialized highlighting for REPL blocks via the julia-repl
attribute on code blocks. Doctests already use this, so this makes the
highlighting for non-doctest REPL blocks consistent.

(cherry picked from commit 014c5d5)
ref #21866

Use at-repl for versioninfo() output

(cherry picked from commit f67d4fd)

Enable highlighting in the manual

A couple of code examples were not highlighted for some reason.

(cherry picked from commit b710de9)

Remove highlighting from REQUIRE code

These blocks are not Julia code, but special REQUIRE file syntax
instead.

(cherry picked from commit c90c17f)

Enable bash highlighting

Also add a newline to the end of the file.

(cherry picked from commit 6e08c18)

Use a non-deprecated package in an example

UTF16.jl has been deprecated for a while. Use SHA.jl instead as the
example.

(cherry picked from commit 6e5c55d)

Edit manual/conversion-and-promotion.md

The REPL example is basically exactly as above, and does not add
anything to the latter bit about the actual convert methods.

(cherry picked from commit 96b65f1)

Fix line numbers in doctests

(cherry picked from commit 814a8a1)

Enable a doctest in base/regex.jl

(cherry picked from commit d9063cb)

Enable doctests the the manual

Switching to julia-repl revealed several code blocks that could
trivially be turned into doctests.

(cherry picked from commit 1d20519)

base/abstractarray.jl

@@ -489,7 +489,7 @@ default is an `Array{element_type}(dims...)`.
 For example, `similar(1:10, 1, 4)` returns an uninitialized `Array{Int,2}` since ranges are
 neither mutable nor support 2 dimensions:
 
-```julia
+```julia-repl
 julia> similar(1:10, 1, 4)
 1×4 Array{Int64,2}:
  4419743872  4374413872  4419743888  0
@@ -498,7 +498,7 @@ julia> similar(1:10, 1, 4)
 Conversely, `similar(trues(10,10), 2)` returns an uninitialized `BitVector` with two
 elements since `BitArray`s are both mutable and can support 1-dimensional arrays:
 
-```julia
+```julia-repl
 julia> similar(trues(10,10), 2)
 2-element BitArray{1}:
  false
@@ -508,7 +508,7 @@ julia> similar(trues(10,10), 2)
 Since `BitArray`s can only store elements of type `Bool`, however, if you request a
 different element type it will create a regular `Array` instead:
 
-```julia
+```julia-repl
 julia> similar(falses(10), Float64, 2, 4)
 2×4 Array{Float64,2}:
  2.18425e-314  2.18425e-314  2.18425e-314  2.18425e-314

base/array.jl

@@ -718,7 +718,7 @@ julia> resize!([6, 5, 4, 3, 2, 1], 3)
  4
 ```
 
-```julia
+```julia-repl
 julia> resize!([6, 5, 4, 3, 2, 1], 8)
 8-element Array{Int64,1}:
  6

base/bitarray.jl

@@ -35,7 +35,7 @@ end
 Construct an uninitialized `BitArray` with the given dimensions.
 Behaves identically to the [`Array`](@ref) constructor.
 
-```julia
+```julia-repl
 julia> BitArray(2, 2)
 2×2 BitArray{2}:
  false  false

base/distributed/pmap.jl

@@ -60,7 +60,7 @@ which is then returned inline with the results to the caller.
 
 Consider the following two examples. The first one returns the exception object inline,
 the second a 0 in place of any exception:
-```julia
+```julia-repl
 julia> pmap(x->iseven(x) ? error("foo") : x, 1:4; on_error=identity)
 4-element Array{Any,1}:
  1

base/docs/helpdb/Base.jl

@@ -1949,7 +1949,7 @@ julia> convert(Int, 3.0)
 julia> convert(Int, 3.5)
 ERROR: InexactError()
 Stacktrace:
- [1] convert(::Type{Int64}, ::Float64) at ./float.jl:679
+ [1] convert(::Type{Int64}, ::Float64) at ./float.jl:680
 ```
 
 If `T` is a `AbstractFloat` or `Rational` type,

base/libgit2/libgit2.jl

@@ -75,7 +75,7 @@ is in the repository.
 
 # Example
 
-```julia
+```julia-repl
 julia> repo = LibGit2.GitRepo(repo_path);
 
 julia> LibGit2.add!(repo, test_file);
@@ -220,7 +220,7 @@ Returns `true` if `a`, a [`GitHash`](@ref) in string form, is an ancestor of
 
 # Example
 
-```julia
+```julia-repl
 julia> repo = LibGit2.GitRepo(repo_path);
 
 julia> LibGit2.add!(repo, test_file1);
@@ -954,4 +954,3 @@ end
 
 
 end # module
-

base/libgit2/reference.jl

@@ -48,7 +48,7 @@ end
 Returns a shortened version of the name of `ref` that's
 "human-readable".
 
-```julia
+```julia-repl
 julia> repo = LibGit2.GitRepo(path_to_repo);
 
 julia> branch_ref = LibGit2.head(repo);

base/libgit2/remote.jl

@@ -78,7 +78,7 @@ Get the URL of a remote git repository.
 
 # Example
 
-```julia
+```julia-repl
 julia> repo_url = "https://github.com/JuliaLang/Example.jl";
 
 julia> repo = LibGit2.clone(cache_repo, "test_directory");
@@ -104,7 +104,7 @@ the name will be an empty string `""`.
 
 # Example
 
-```julia
+```julia-repl
 julia> repo_url = "https://github.com/JuliaLang/Example.jl";
 
 julia> repo = LibGit2.clone(cache_repo, "test_directory");
@@ -158,7 +158,7 @@ Add a *fetch* refspec for the specified `rmt`. This refspec will contain
 information about which branch(es) to fetch from.
 
 # Example
-```julia
+```julia-repl
 julia> LibGit2.add_fetch!(repo, remote, "upstream");
 
 julia> LibGit2.fetch_refspecs(remote)
@@ -178,7 +178,7 @@ Add a *push* refspec for the specified `rmt`. This refspec will contain
 information about which branch(es) to push to.
 
 # Example
-```julia
+```julia-repl
 julia> LibGit2.add_push!(repo, remote, "refs/heads/master");
 
 julia> remote = LibGit2.get(LibGit2.GitRemote, repo, branch);

base/multidimensional.jl

@@ -903,7 +903,7 @@ their indices; any offset results in a (circular) wraparound. If the
 arrays have overlapping indices, then on the domain of the overlap
 `dest` agrees with `src`.
 
-```julia
+```julia-repl
 julia> src = reshape(collect(1:16), (4,4))
 4×4 Array{Int64,2}:
  1  5   9  13

base/regex.jl

@@ -75,7 +75,7 @@ after the ending quote, to change its behaviour:
 
 For example, this regex has all three flags enabled:
 
-```julia
+```jldoctest
 julia> match(r"a+.*b+.*?d\$"ism, "Goodbye,\\nOh, angry,\\nBad world\\n")
 RegexMatch("angry,\\nBad world")
 ```

base/util.jl

@@ -82,7 +82,7 @@ gc_bytes() = ccall(:jl_gc_total_bytes, Int64, ())
 Set a timer to be read by the next call to [`toc`](@ref) or [`toq`](@ref). The
 macro call `@time expr` can also be used to time evaluation.
 
-```julia
+```julia-repl
 julia> tic()
 0x0000c45bc7abac95
 
@@ -105,7 +105,7 @@ end
 Return, but do not print, the time elapsed since the last [`tic`](@ref). The
 macro calls `@timed expr` and `@elapsed expr` also return evaluation time.
 
-```julia
+```julia-repl
 julia> tic()
 0x0000c46477a9675d
 
@@ -132,7 +132,7 @@ end
 Print and return the time elapsed since the last [`tic`](@ref). The macro call
 `@time expr` can also be used to time evaluation.
 
-```julia
+```julia-repl
 julia> tic()
 0x0000c45bc7abac95
 
@@ -219,7 +219,7 @@ returning the value of the expression.
 See also [`@timev`](@ref), [`@timed`](@ref), [`@elapsed`](@ref), and
 [`@allocated`](@ref).
 
-```julia
+```julia-repl
 julia> @time rand(10^6);
   0.001525 seconds (7 allocations: 7.630 MiB)
 
@@ -253,7 +253,7 @@ expression.
 See also [`@time`](@ref), [`@timed`](@ref), [`@elapsed`](@ref), and
 [`@allocated`](@ref).
 
-```julia
+```julia-repl
 julia> @timev rand(10^6);
   0.001006 seconds (7 allocations: 7.630 MiB)
 elapsed time (ns): 1005567
@@ -282,7 +282,7 @@ number of seconds it took to execute as a floating-point number.
 See also [`@time`](@ref), [`@timev`](@ref), [`@timed`](@ref),
 and [`@allocated`](@ref).
 
-```julia
+```julia-repl
 julia> @elapsed sleep(0.3)
 0.301391426
 ```
@@ -314,7 +314,7 @@ for the effects of compilation.
 See also [`@time`](@ref), [`@timev`](@ref), [`@timed`](@ref),
 and [`@elapsed`](@ref).
 
-```julia
+```julia-repl
 julia> @allocated rand(10^6)
 8000080
 ```
@@ -343,7 +343,7 @@ counters.
 See also [`@time`](@ref), [`@timev`](@ref), [`@elapsed`](@ref), and
 [`@allocated`](@ref).
 
-```julia
+```julia-repl
 julia> val, t, bytes, gctime, memallocs = @timed rand(10^6);
 
 julia> t

doc/src/devdocs/backtraces.md

@@ -18,18 +18,8 @@ No matter the error, we will always need to know what version of Julia you are r
 first starts up, a header is printed out with a version number and date.  If your version is
 `0.2.0` or higher, please include the output of `versioninfo()` in any report you create:
 
-```julia
-julia> versioninfo()
-Julia Version 0.3.3-pre+25
-Commit 417b50a* (2014-11-03 11:32 UTC)
-Platform Info:
-  OS: Linux (x86_64-linux-gnu)
-  CPU: Intel(R) Core(TM) i7 CPU       L 640  @ 2.13GHz
-  WORD_SIZE: 64
-  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
-  LAPACK: libopenblas
-  LIBM: libopenlibm
-  LLVM: libLLVM-3.3
+```@repl
+versioninfo()
 ```
 
 ## Segfaults during bootstrap (`sysimg.jl`)

doc/src/devdocs/cartesian.md

@@ -53,9 +53,19 @@ is `@nref 3 A i` (as in `A[i_1,i_2,i_3]`, where the array comes first).
 If you're developing code with Cartesian, you may find that debugging is easier when you examine
 the generated code, using `macroexpand`:
 
-```julia
+```@meta
+DocTestSetup = quote
+    import Base.Cartesian: @nref
+end
+```
+
+```jldoctest
 julia> macroexpand(:(@nref 2 A i))
-:(A[i_1,i_2])
+:(A[i_1, i_2])
+```
+
+```@meta
+DocTestSetup = nothing
 ```
 
 ### Supplying the number of expressions

doc/src/devdocs/reflection.md

@@ -14,7 +14,7 @@ The names of `DataType` fields may be interrogated using [`fieldnames()`](@ref).
 given the following type, `fieldnames(Point)` returns an arrays of [`Symbol`](@ref) elements representing
 the field names:
 
-```julia
+```jldoctest struct_point
 julia> struct Point
            x::Int
            y
@@ -29,17 +29,17 @@ julia> fieldnames(Point)
 The type of each field in a `Point` object is stored in the `types` field of the `Point` variable
 itself:
 
-```julia
+```jldoctest struct_point
 julia> Point.types
-svec(Int64,Any)
+svec(Int64, Any)
 ```
 
 While `x` is annotated as an `Int`, `y` was unannotated in the type definition, therefore `y`
 defaults to the `Any` type.
 
 Types are themselves represented as a structure called `DataType`:
 
-```julia
+```jldoctest struct_point
 julia> typeof(Point)
 DataType
 ```
@@ -52,9 +52,9 @@ of these fields is the `types` field observed in the example above.
 The *direct* subtypes of any `DataType` may be listed using [`subtypes()`](@ref). For example,
 the abstract `DataType``AbstractFloat` has four (concrete) subtypes:
 
-```julia
+```jldoctest
 julia> subtypes(AbstractFloat)
-4-element Array{DataType,1}:
+4-element Array{Union{DataType, UnionAll},1}:
  BigFloat
  Float16
  Float32
@@ -83,9 +83,9 @@ the unquoted and interpolated expression (`Expr`) form for a given macro. To use
 `quote` the expression block itself (otherwise, the macro will be evaluated and the result will
 be passed instead!). For example:
 
-```julia
+```jldoctest
 julia> macroexpand( :(@edit println("")) )
-:((Base.edit)(println,(Base.typesof)("")))
+:((Base.edit)(println, (Base.typesof)("")))
 ```
 
 The functions `Base.Meta.show_sexpr()` and [`dump()`](@ref) are used to display S-expr style views
@@ -95,11 +95,11 @@ Finally, the [`expand()`](@ref) function gives the `lowered` form of any express
 particular interest for understanding both macros and top-level statements such as function declarations
 and variable assignments:
 
-```julia
+```jldoctest
 julia> expand( :(f() = 1) )
 :(begin
         $(Expr(:method, :f))
-        $(Expr(:method, :f, :((Core.svec)((Core.svec)((Core.Typeof)(f)),(Core.svec)())), CodeInfo(:(begin  # none, line 1:
+        $(Expr(:method, :f, :((Core.svec)((Core.svec)((Core.Typeof)(f)), (Core.svec)())), CodeInfo(:(begin  # none, line 1:
         return 1
     end)), false))
         return f
@@ -123,7 +123,7 @@ generation for any function which has not previously been called).
 For convenience, there are macro versions of the above functions which take standard function
 calls and expand argument types automatically:
 
-```julia
+```julia-repl
 julia> @code_llvm +(1,1)
 
 ; Function Attrs: sspreq

doc/src/devdocs/subarrays.md

@@ -54,7 +54,7 @@ any runtime overhead.
 
 The strategy adopted is first and foremost expressed in the definition of the type:
 
-```
+```julia
 struct SubArray{T,N,P,I,L} <: AbstractArray{T,N}
     parent::P
     indexes::I
@@ -74,7 +74,7 @@ If in our example above `A` is a `Array{Float64, 3}`, our `S1` case above would
 Note in particular the tuple parameter, which stores the types of the indices used to create
 `S1`.  Likewise,
 
-```julia
+```julia-repl
 julia> S1.indexes
 (Colon(),5,2:6)
 ```
@@ -89,7 +89,7 @@ types.  For example, for `S1`, one needs to apply the `i,j` indices to the first
 of the parent array, whereas for `S2` one needs to apply them to the second and third.  The simplest
 approach to indexing would be to do the type-analysis at runtime:
 
-```
+```julia
 parentindexes = Array{Any}(0)
 for thisindex in S.indexes
     ...
@@ -137,7 +137,7 @@ For `SubArray` types, the availability of efficient linear indexing is based pur
 of the indices, and does not depend on values like the size of the parent array. You can ask whether
 a given set of indices supports fast linear indexing with the internal `Base.viewindexing` function:
 
-```julia
+```julia-repl
 julia> Base.viewindexing(S1.indexes)
 IndexCartesian()
 
@@ -152,7 +152,7 @@ we can define dispatch directly on `SubArray{T,N,A,I,true}` without any intermed
 Since this computation doesn't depend on runtime values, it can miss some cases in which the stride
 happens to be uniform:
 
-```julia
+```jldoctest
 julia> A = reshape(1:4*2, 4, 2)
 4×2 Base.ReshapedArray{Int64,2,UnitRange{Int64},Tuple{}}:
  1  5
@@ -171,7 +171,7 @@ A view constructed as `view(A, 2:2:4, :)` happens to have uniform stride, and th
 indexing indeed could be performed efficiently.  However, success in this case depends on the
 size of the array: if the first dimension instead were odd,
 
-```julia
+```jldoctest
 julia> A = reshape(1:5*2, 5, 2)
 5×2 Base.ReshapedArray{Int64,2,UnitRange{Int64},Tuple{}}:
  1   6