implement feature(const_generics_defaults)

[JulianKnodt]

Implements const generics defaults struct Example<const N: usize=3>, as well as a query for getting the default of a given const-parameter's def id. There are some remaining FIXME's but they were specified as not blocking for merging this PR. This also puts the defaults behind the unstable feature gate #![feature(const_generics_defaults)].

This currently creates a field which is always false on GenericParamDefKind for future use when
consts are permitted to have defaults. I'm not sure if this is exactly what is best for adding default parameters, but I mimicked the style of type defaults, so hopefully this is ok.

r? @lcnr

[bors]

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

[lcnr]

Hmm, I am not sure how easy it is to start here and think that's it's probably better to start by actually parsing const N: Type = expr, so we can test these changes.

Do we want to implement this as part of const_generics or do we want a new feature gate for this?

Also, while I will review this, I won't merge it myself, so r? @varkor

[varkor]

I think if we're going to make any progress with defaults for const generics, we ought to try to implement them in a single PR, or at least bigger steps than this. Otherwise we risk making implementation choices that aren't the best in practice, and then refactoring unnecessarily later. You're welcome to try implementing defaults, though: I think we'll want an extra feature flag const_generics_defaults, because it's likely we won't stabilise them along with the rest of const generics (they weren't part of the original RFC). There are lots of FIXME(const_generics:defaults) throughout the code that should pinpoint most of the places that need changing accordingly.

[JulianKnodt]

Hm I think I added all the points where I saw the FIXME(const_generics:defaults), but as this would be a larger change maybe I'll hold off for a bit

[varkor]

Oh, sorry, I hadn't actually looked at the changes yet. Maybe this actually isn't too far off a minimal working implementation? Maybe if you tried implementing the parser changes, we could get a better idea of what does or doesn't work?

[bors]

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

[JulianKnodt]

Hm I'm a little stuck at this point, I'm not particularly sure where the error could be originating from.

[JohnCSimon]

@JulianKnodt - ping from triage, can you please address the merge conflicts?

[bors]

📌 Commit 33370fd has been approved by varkor,lcnr

[Dylan-DPC-zz]

@bors retry

[bors]

⌛ Testing commit 33370fd with merge c964c9ae35ee07abd1712a8f902a6f3852d059bb...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[varkor]

@bors retry

[bors]

⌛ Testing commit 33370fd with merge 5b33de3...

[bors]

☀️ Test successful - checks-actions
Approved by: varkor,lcnr
Pushing 5b33de3 to master...

[varkor]

@JulianKnodt: thank you for all your hard work pushing this feature to completion!

[rylev]

@JulianKnodt @varkor - there was a slight performance regression seen after a performance run of this change. It's fairly small and it only impacts one benchmark which does not use const generics at all. The specific query impacted is generate_crate_metadata, but from the changes it doesn't look like metadata encoding changed very much at all. Any ideas?

[JulianKnodt]

Probably CGU partitioning changed after the queries changed?

[mati865]

generate_crate_metadata takes longer now, I doubt it's related to CGU partitioning.

I'd also say this is expected perf change given what this does.