Add long diagnostics for E0018

[GuillaumeGomez]

Part of #24407.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[apasel422]

s/the compile-time which/compile time, which/

[GuillaumeGomez]

I'm don't get your point.

[bombless]

He means "... value of static and const variables must be known at compile time, which is ...".
And I think he's right.

[GuillaumeGomez]

Oh right ! Thanks !

[pnkfelix]

Don't you need to delete the other entry too?

[GuillaumeGomez]

@pnkfelix: Totally, thanks for noticing me !

[GuillaumeGomez]

And it's done !

[bors]

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

[GuillaumeGomez]

@apasel422: Did you find another way ? For my french mind, it seems totally fine haha.

[michaelsproul]

I think the explanation needs a bit more detail to fully convey the subtlety of this error. Pointers are allowed in const items, just not pointers cast to integers. See RFC 246, particularly the section on const => const and the bug that introduced this error, #18294.

I think an ideal explanation for this error should cover these points:

• Pointers to other constants are allowed in constants, although the address will be non-constant.

// This is fine.constX:u32 = 50;constY:*constu32 = &X;println!("{:?}",Y);

• Therefore, casting one of these non-constant pointers to an integer results in a non-constant integer (as observed by running the above program), thus triggering E0018.

You could also link to the RFC and the issue.

[GuillaumeGomez]

@michaelsproul: I don't think giving links to RFC/issue was a good idea. I added your explanations. Do you find something else to correct or add ?

[michaelsproul]

This looks great except for the second sentence here. I think integer as a pointer should be pointer as an integer and what value will be at the address should be what value the address will take.

[GuillaumeGomez]

@michaelsproul: It's corrected ! Thanks again !

[michaelsproul]

@GuillaumeGomez: Looks good to me 👍

[pnkfelix]

typo: "whichs lead to this error" is not correct. Should be "which"

[GuillaumeGomez]

@pnkfelix: It's corrected, thanks !

[pnkfelix]

@bors r+ 737005a rollup

[bors]

⌛ Testing commit 737005a with merge fe11393...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt