QUrl doesn't accept string with ';' in the host

As per the discussion in QTBUG-98384, creating a QUrl from the string

hansoft://localhost;AutomatedTests;9d25e2c7/Task/527?ID=21

should result in a valid QUrl, but it doesn't. To quote Eddy:

To parse hansoft://localhost;AutomatedTests;9d25e2c7/Task/527?ID=21 as an URL, RFC 3986's rules tell me to split it up as:

• scheme: hansoft
• literal :
• hier-part: //localhost;AutomatedTests;9d25e2c7/Task/527
• literal ?
• query: ID=21

(no literal #, so no fragment identifier), with the hier-part in turn parsing as:

• literal: //
• authority: localhost;AutomatedTests;9d25e2c7 (terminated by the next /)
• path-abempty: /Task/527

however, with no @ (hence userinfo) or : (hence port) in the authority, it must be read as host.
Lack of enclosing [...] on the host precludes reading host as IP-literal, hence as IPv6address or IPvFuture; lack of dots in host precludes parsing it as IPv4address, leaving only reg-name.
Since reg-name does allow sub-delims (hence semicolon) along with alphanumerics, there is no reason to object to parsing that authority as

• host: localhost;AutomatedTests;9d25e2c7

It's a bit eccentric, but nothing in RFC 3986, section 3 precludes this reading. While

This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg-name beyond what is necessary for interoperability. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. However, a globally scoped naming system, such as DNS fully qualified domain names, is necessary for URIs intended to have global scope. URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length.

does strongly encourage a DNS-comatible format, this only constrains resolving a host, not encoding it in a URL. So indeed QUrl should cope; the fact that it does not is a bug, albeit somewhat of a corner case.