IDLParserContext unary constructor missing "explicit".
This constructor takes a StringData, which means a StringData is usable where an IDLParserContext is expected. This is not the right way to do it, and it's confusing because StringData is itself implicitly convertible from so many things, and none of THOSE things are usable as IDLParserContext, so people either use ""_sd literals or braces around a string literal to force the construction of a StringData argument.

The IDLParserContext is not a string-like type and should not be implicitly convertible from StringData. If the IDL-generated parse functions want to have an overload that takes StringData, that's one thing, but that's not what this is.

Related to SERVER-66708, where IDLParserContext constructors are having a hard time being properly defined because of these use cases relying on the implicit constructor.

Recommendation is to make the constructor explicit and fix all call sites.