Hubert Plociniczak e163353d16 Deprecate Error's to_display_text builtin methods (#6275) ... The primary motivation for this change was https://github.com/enso-org/enso/issues/6248, which requested the possibility of defining `to_display_text` methods of common errors via regular method definitions. Until now one could only define them via builtins. To be able to support that, polyglot invocation had to report `to_display_text` in the list of (invokable) members, which it didn't. Until now, it only considered fields of constructors and builtin methods. That is now fixed as indicated by the change in `Atom`. Closes #6248. # Important Notes Once most of builtins have been translated to regular Enso code, it became apparent how the usage of `.` at the end of the message is not consistent and inflexible. The pure message should never follow with a dot or it makes it impossible to pretty print consistently for the purpose of error reporting. Otherwise we regularly end up with errors ending with `..` or worse. So I went medieval on the reasons for failures and removed all the dots. The overall result is mostly the same except now we are much more consistent. Finally, there was a bit of a good reason for using builtins as it simplified our testing. Take for example `No_Such_Method.Error`. If we do not import `Errors.Common` module we only rely on builtin error types. The type obviously has the constructor but it **does not have** `to_display_text` in scope; the latter is no longer a builtin method but a regular method. This is not really a problem for users who will always import stdlib but our tests often don't. Hence the number of changes and sometimes lack of human-readable errors there.		2023-04-14 19:14:49 +00:00
..
editions	introduce a micro stdlib for testing (#3531)	2022-06-16 10:25:24 +00:00
lib/Standard/Base/0.0.0-dev	Deprecate Error's to_display_text builtin methods (#6275)	2023-04-14 19:14:49 +00:00