feat(builtin): add dump() for easy print-based debugging

[rami3l]

dbg!() is a very popular Rust std macro that can be used like so:

let a = 2;
let b = dbg!(a * 2) + 1;
//      ^-- prints: [src/main.rs:2:9] a * 2 = 4
assert_eq!(b, 5);

... note that a * 2 is not only printed for debugging but also passed on to the rest of the calculation, which makes it a perfect fit for inspecting complex evaluations such as those of chained method calls.

The idea of this PR is to mimic the behavior of that macro with what is currently available with MoonBit's compiler magic, i.e. loc~ : SourceLoc = _ and "%any.to_string".

The signature of this function dump() is as follows:

pub fn dump[T](t : T, name? : String, loc~ : SourceLoc = _) -> T 

... where the identifiers dump and name are taken from a similar Swift function.

[rami3l]

This function is marked as deprecated because it seems to be the only way to generate warnings with it. In Rust this logic is handled by clippy instead of rustc so there haven't been such concerns.

[coveralls]

Pull Request Test Coverage Report for Build 4341

Details

• 0 of 3 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.05%) to 83.3%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
builtin/console.mbt	0	3	0.0%

Totals
Change from base Build 4338:	-0.05%
Covered Lines:	4634
Relevant Lines:	5563

---

💛 - Coveralls

[bobzhang]

any_to_string is introduced for arbitrary code transformations where T is not sure if it satsifies Show. How is this different from dump[T:Show](...)
cc @Guest0x0 it makes sense to introduce support of ArgsRepr which is essentialy a stringified repr of args. so that we can do something like this:

pub fn dump[T:Show](t : T, name~ : ArgsRepr = _, loc~ : SourceLoc = _) -> T

[rami3l]

@bobzhang One thing that distinguishes Swift's dump() from Rust's dbg!() is that the former doesn't pose any restrictions on T whereas the latter depends on T: Debug (which is exclusively used for print-oriented pretty-printing, compensating for the lack of a built-in dumper in Rust) ¹.

I think the Show trait in MoonBit corresponds to the Display trait (which subsumes .to_string() in Rust) rather than Debug, so it makes more sense to add no bounds at all.

OTOH ArgsRepr will definitely be a nice addition.

Footnotes

1. The lack of distinction between Display and Debug seems like a common reason for which print-based debugging is less popular in traditional tech stacks; both approaches here allow the mitigation of this issue. ↩

[peter-jerry-ye-code-review]

‼️ This code review is generated by a bot. Please verify the content before trusting it.

Here are three observations and potential issues from the provided git diff output:

1. Deprecated Function Usage:

   • The dump function is marked as deprecated in builtin.mbti with the comment //deprecated. However, it is being implemented in console.mbt without any clear indication of its deprecation status in the implementation. This inconsistency could lead to confusion for developers. It would be better to include a deprecation warning or note in the implementation as well, similar to the @alert deprecated comment in the function's documentation.

2. String Interpolation Syntax:

   • In the dump function implementation in console.mbt, the string interpolation syntax \{name} and \{loc} is used. Ensure that this syntax is supported and correctly interpreted by the language or framework being used. If not, it might lead to runtime errors or unexpected behavior.

3. Function Naming and Purpose:

   • The dump function is described as being for "quick and dirty debugging" and is marked as deprecated. However, its implementation suggests it could be useful for debugging purposes. If this function is indeed useful, consider renaming it to something more descriptive (e.g., debug_print) and removing the deprecation marker. If it is truly deprecated, ensure that it is removed from all relevant files and that alternative debugging methods are documented.

These issues should be addressed to maintain code clarity, consistency, and functionality.