FailureToEliminateExistential

The explanation should provide a detailed description of why the error occurred and use examples from the user's own code to illustrate how to avoid these errors. It might contain embedded tags.

The kind of the error message, e.g. "Syntax" or "Type Mismatch". This will be printed as "$kind Error", "$kind Warning", etc, on the first line of the message.

The msg contains the diagnostic message e.g:

expected: String found: Int

This message will be placed underneath the position given by the enclosing Diagnostic. The message is given in raw form, with possible embedded tags.

Does this message have an explanation? This is normally the same as explain.nonEmpty but can be overridden if we need a way to return true without actually calling the explain method.

A message is non-sensical if it contains references to tags. Such tags are inserted by the error diagnostic framework if a message contains references to internally generated error types. Normally we want to suppress error messages referring to types like this because they look weird and are normally follow-up errors to something that was diagnosed before.

The implicit Context in messages is a large thing that we don't want persisted. This method gets around that by duplicating the message, forcing its msg and explanation vals and dropping the implicit context that was captured in the original message.

The message with potential embedded tags

Override with true for messages that should always be shown even if their position overlaps another messsage of a different class. On the other hand multiple messages of the same class with overlapping positions will lead to only a single message of that class to be issued.

Returns a string representation of the object.

The default representation is platform dependent.

The explanation to report. tags are filtered out

The message to report. tags are filtered out