feat: inline const as literal by viktorlott · Pull Request #14925 · rust-lang/ru... - JOYK Joy of Geek, Geek News, Link all geek

Conversation

Contributor

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!"
}

rustbot

added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label

May 29, 2023

viktorlott

force-pushed the inline-const-expr-as-static-str

branch 6 times, most recently from 489d5e0 to 1e803cc Compare

May 29, 2023 20:53

viktorlott

marked this pull request as ready for review

May 29, 2023 21:10

Member

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)

Veykril reacted with thumbs up emoji

Contributor

Author

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?~~

Member

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.

viktorlott reacted with thumbs up emoji

viktorlott

force-pushed the inline-const-expr-as-static-str

branch 2 times, most recently from 579db63 to ae3be8e Compare

May 31, 2023 10:34

viktorlott

changed the title ~~feat: inline const expr as static str~~

feat: inline const as literal

May 31, 2023

viktorlott

force-pushed the inline-const-expr-as-static-str

branch 3 times, most recently from 21d83a5 to d68d11e Compare