logging: string->String

[timholy]

This is from #44500. Note it's against backports-release-1.8

This is good material for 1.8 because of the introduction of LazyString, which will probably be used heavily by the logging framework.

[JeffBezanson]

Do we know what types message can have? Otherwise this might not work.

[timholy]

It has to be AbstractString because that's required for eachsplit. Before I added any types this was just msglines = eachsplit(message, '\n') (EDIT: that probably isn't right, it was probably msglines = eachsplit(string(message,) '\n').) With this change, you can do @warn LazyString(args...).

For Julia 2.0 we should rework the logging framework to specify some types on at least some of its variables. Code from the logging framework gets inserted into everything, and having it wide-open without any type annotations whatsoever causes so many vulnerabilities for invalidation. Either that or (1) write it in C, (2) hide it in a module like Core that won't invalidate, or (3) all logging code has to be hidden behind runtime dispatch.

[fredrikekre]

message can be anything:

julia> @info sum
[ Info: sum

but with this PR this would throw a MethodError. Non-AbstractString messages are used quite a lot in code in the wild.

[timholy]

Didn't know that, thanks @fredrikekre. Unfortunate, then, that the entire test suite (esp. corelogging.jl) passed with the change I made.

[timholy]

I'll wait to merge this until #44550#44500 goes in.

[KristofferC]

Hm, I don't see how that PR is related to this.

[timholy]

Good point. Fixed.

[DilumAluthge]

This is from #44500. Note it's against backports-release-1.8

@KristofferC @timholy Note that this PR was not actually merged into backports-release-1.8. Instead, it was merged into release-1.8. This is because GitHub automatically change the base (target) branch of this PR two days ago.

[timholy]

Ugh, is this something we need to revert? Or what's the right way to handle it? FWIW I don't think this is a very risky PR.