round(Float64, 1.2) is documented to return 1.0, but throws.

[LilithHafner]

help?> round(Float64, 1.2)
  round([T,] x, [r::RoundingMode])
  round(x, [r::RoundingMode]; digits::Integer=0, base = 10)
  round(x, [r::RoundingMode]; sigdigits::Integer, base = 10)

  Rounds the number x.

  Without keyword arguments, x is rounded to an integer value, returning a value 
  of type T, or of the same type of x if no T is provided. An InexactError will be 
  thrown if the value is not representable by T, similar to convert.

...

julia> round(Float64, 1.2)
ERROR: MethodError: no method matching round(::Type{Float64}, ::Float64)

Closest candidates are:
  round(::Type{Bool}, ::AbstractFloat)
   @ Base float.jl:391
  round(::Type{T}, ::AbstractFloat, ::RoundingMode) where T<:Integer
   @ Base floatfuncs.jl:122
  round(::Type{T}, ::AbstractFloat) where T<:Integer
   @ Base float.jl:385
  ...

Stacktrace:
 [1] top-level scope
   @ REPL[13]:1

[oscardssmith]

yeah that's a bug

[oscardssmith]

Also, when you fix this make sure that round(Float32, 1e60) and round(Float32, floatmax(Float32)-1.0) throw inexact errors.

[LilithHafner]

The docstring says

An InexactError will be thrown if the value is not representable by T, similar to convert.

but looking at the behavior of convert, convert(Float32, 1e60) == Inf32—it does not throw. The documented criterion is "representable" not "exactly representable".

Also, the implementation is simpler if this does not throw.

[Seelengrab]

The "similar to" indicates to me that it's not about the exact behavior of convert, but whether the value is losslessy convertible. That is not possible with Inf32, though the docstring should probably clarify that.