Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make format_args!("literal") const. #87005

Closed
wants to merge 1 commit into from

Conversation

m-ou-se
Copy link
Member

@m-ou-se m-ou-se commented Jul 9, 2021

This makes format_args!("literal") const, while leaving all other invocations of format_args!() non-const.

cc @rust-lang/wg-const-eval

@m-ou-se m-ou-se self-assigned this Jul 9, 2021
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 9, 2021
@m-ou-se m-ou-se added needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jul 9, 2021
@rust-log-analyzer

This comment has been minimized.

@m-ou-se m-ou-se marked this pull request as draft July 9, 2021 20:54
const B: std::fmt::Arguments = format_args!("{}", 123);
//~^ ERROR calls in constants are limited to
//~| ERROR calls in constants are limited to
//~| ERROR temporary value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are there 3 errors here and not just the one we'd expect? I guess that comes from the extra code for the argument 123? "temporary value dropped while borrowed" is a bit odd though...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"temporary value dropped while borrowed" is a bit odd though...

It expands to

::core::fmt::Arguments::new_v1(
    &[""],
    &match (&123,) {
        (arg0,) => [::core::fmt::ArgumentV1::new(
            arg0,
            ::core::fmt::Display::fmt,
        )],
    },
);

The [::core::fmt::ArgumentV1::new(arg0, ::core::fmt::Display::fmt)] is here borrowed and then dropped before the end of the borrow.

Copy link
Member

@RalfJung RalfJung Jul 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah right that would not be promoted.
Better change the test do

const B: () = {
  let _ = format_args!(...);
};

@@ -0,0 +1,8 @@
#![crate_type = "lib"]

const A: std::fmt::Arguments = format_args!("literal");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is insta-stable?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it's just not gated in this WIP form of the PR

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is insta-stable?

Yes. That's why I added needs-fcp.

@oli-obk
Copy link
Contributor

oli-obk commented Jul 10, 2021

i don't think we should make this pattern special. we could just allow format_args in general, just like we allow range syntax, but there's no use for the value you get, unless you use it to panic.

/// Arguments structure in case it's just a single string literal.
#[doc(hidden)]
#[inline]
#[unstable(feature = "fmt_internals", reason = "internal to format_args!", issue = "none")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to make it const-unstable at the same time under a different feature gate?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is const-unstable (implicitly). But the format_args! macro expanded code has some kind of span that still lets stable code call this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the fmt_internals feature is allowed:

#[allow_internal_unstable(fmt_internals)]

Using a different feature for const checking would require this feature to be enabled by the user of format_args!.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason i want this is so panic!() can use this for const panic. (See #86998) Putting an allow_internal_unstable(const_fmt_internals) on the panic macro won't work through the nested format_args call.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would at least prevent it from being insta-stable, right? Maybe use const_panic as feature gate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should just go for the const_format_args!() macro for now (#86998) and at some point stabilize format_args!() in const entirely. (And then remove const_format_args!() again.)

@bors
Copy link
Contributor

bors commented Aug 24, 2021

☔ The latest upstream changes (presumably #83302) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Nov 9, 2021

☔ The latest upstream changes (presumably #90485) made this pull request unmergeable. Please resolve the merge conflicts.

@Mark-Simulacrum
Copy link
Member

@m-ou-se it seems like we can likely close this now -- I think the broader goal still probably makes sense (making format_args! const in general) and we worked around this for the panic case already, so there's not really that much need for the targeted adjustment here?

@Dylan-DPC
Copy link
Member

Closing this based on comment

@Dylan-DPC Dylan-DPC closed this Mar 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants