feat: inline const as literal

[viktorlott]

Assist: inline_const_as_literal

Evaluate and inline const variable as literal.

const STRING: &str = "Hello, World!";

fn something() -> &'static str {
    STR$0ING
}

->

const STRING: &str = "Hello, World!";

fn something() -> &'static str {
    "Hello, World!"
}

[HKalbasi]

Interesting assist. Why it's name is limited to string literals? I think the current code works with integers and other kinds of literals without any changes, and with some trivial changes it could support arrays and tuples (supporting structs and enums are a little harder I think)

[viktorlott]

Interesting assist. Why it's name is limited to string literals? I think the current code works with integers and other kinds of literals without any changes, and with some trivial changes it could support arrays and tuples (supporting structs and enums are a little harder I think)

That was actually my initial intention, but I decided to scope it to &str because I had some trouble applying effective tests for all the cases (e.g testing built-in/proc macros and evaluating blocks with resource locks). But yeah, we could rescope it such that other primitive types also work.

Should I include lazy const expressions also, or just avoid ADTs all together?

[HKalbasi]

That was actually my initial intention, but I decided to scope it to &str because I had some trouble applying effective tests for all the cases (e.g testing built-in/proc macros and evaluating blocks with resource locks). But yeah, we could rescope it such that other primitive types also work.

It's fine if this PR only supports &str and other cases are deferred to future (I think it already supports some more things, but anyway), just using general words for name and message of the assist is good enough for start.

Should I include lazy const expressions also, or just avoid ADTs all together?

By those, you mean expressions that contains closures? I guess those are theoretically impossible to support. For adt the problem is private fields, unresolved names, names that need to be imported and similar things, so I think it should avoid ADTs.

[HKalbasi]

Can you also add some negative tests for cases that their type is not supported (adt, closure, ...)?

[viktorlott]

Absolutely,
Are the newly added tests enough, or should I add more variance to them?

[HKalbasi]

#14947 fixes some of the render_eval problems in this PR tests.

[viktorlott]

#14947 fixes some of the render_eval problems in this PR tests.

Great! I'll take a look at your comments after work

[HKalbasi]

Thanks!
@bors r+

[bors]

📌 Commit eef716d has been approved by HKalbasi

It is now in the queue for this repository.

[bors]

⌛ Testing commit eef716d with merge 058e2d2...

[bors]

☀️ Test successful - checks-actions
Approved by: HKalbasi
Pushing 058e2d2 to master...