Tracking Issue for associated const equality #92827
Comments
JulianKnodt
added
the
C-tracking-issue
Continue work on associated const equality This actually implements some more complex logic for assigning associated consts to values. Inside of projection candidates, it now defers to a separate function for either consts or types. To reduce amount of code, projections are now generic over T, where T is either a Type or a Const. I can add some comments back later, but this was the fastest way to implement it. It also now finds the correct type of consts in type_of. --- The current main TODO is finding the const of the def id for the LeafDef. Right now it works if the function isn't called, but once you use the trait impl with the bound it fails inside projection. I was hoping to get some help in getting the `&'tcx ty::Const<'tcx>`, in addition to a bunch of other `todo!()`s which I think may not be hit. r? `@oli-obk` Updates rust-lang#92827
|
Well, we have #70256 which indeed has basically no discussion of the feature. It just seemed like an oversight to have associated types + associated type bounds, but only associated consts without any bounds for them. |
|
I probably should've tagged the original issue in this at the start (it was in the original PR if I remember correctly) but I'm bad at leaving a thorough paper trail. I'll add a reference to the original issue in the issue itself, and if there's more work that needs to be done please let know |
|
You did everything correctly. I found the issue because you did link it in the first sentence in this issue 😄 We should probably do a lang team MCP for it along with some medium sized doc explaining what is going on and why. I'll open a hackmd and then we can collab on it |
=== stdout ===
=== stderr ===
error: comparison operators cannot be chained
--> /home/runner/work/glacier/glacier/ices/93835.rs:2:8
|
1 | fn e() {
| - while parsing this struct
2 | p:a<p:p<e=6>>
| ^ ^
|
= help: use `::<...>` instead of `<...>` to specify lifetime, type, or const arguments
= help: or use `(...)` if you meant to specify fn arguments
error[E0425]: cannot find value `p` in this scope
--> /home/runner/work/glacier/glacier/ices/93835.rs:2:5
|
2 | p:a<p:p<e=6>>
| ^ not found in this scope
|
help: you might have meant to write a `struct` literal
|
1 ~ fn e() { SomeStruct {
2 | p:a<p:p<e=6>>
3 ~ }}
|
help: maybe you meant to write a path separator here
|
2 | p::a<p:p<e=6>>
| ~~
help: maybe you meant to write an assignment here
|
2 | let p:a<p:p<e=6>>
| ~~~~~
error[E0658]: associated const equality is incomplete
--> /home/runner/work/glacier/glacier/ices/93835.rs:2:13
|
2 | p:a<p:p<e=6>>
| ^^^
|
= note: see issue #92827 <rust-lang/rust#92827> for more information
= help: add `#![feature(associated_const_equality)]` to the crate attributes to enable
error[E0658]: associated type bounds are unstable
--> /home/runner/work/glacier/glacier/ices/93835.rs:2:9
|
2 | p:a<p:p<e=6>>
| ^^^^^^^^
|
= note: see issue #52662 <rust-lang/rust#52662> for more information
= help: add `#![feature(associated_type_bounds)]` to the crate attributes to enable
error[E0601]: `main` function not found in crate `93835`
--> /home/runner/work/glacier/glacier/ices/93835.rs:1:1
|
1 | / fn e() {
2 | | p:a<p:p<e=6>>
3 | | }
| |_^ consider adding a `main` function to `/home/runner/work/glacier/glacier/ices/93835.rs`
error: aborting due to 5 previous errors
Some errors have detailed explanations: E0425, E0601, E0658.
For more information about an error, try `rustc --explain E0425`.
==============
dtolnay
added
A-associated-items
=== stdout ===
=== stderr ===
error[E0658]: associated const equality is incomplete
--> /home/runner/work/glacier/glacier/ices/99828.rs:1:43
|
1 | fn get_iter(vec: &[i32]) -> impl Iterator<Item = {}> + '_ {
| ^^^^^^^^^
|
= note: see issue #92827 <rust-lang/rust#92827> for more information
= help: add `#![feature(associated_const_equality)]` to the crate attributes to enable
error: expected associated type bound, found constant
--> /home/runner/work/glacier/glacier/ices/99828.rs:1:43
|
1 | fn get_iter(vec: &[i32]) -> impl Iterator<Item = {}> + '_ {
| ^^^^^^^^^
|
note: associated type defined here
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0658`.
==============
joshtriplett
added
the
S-tracking-needs-summary
|
What's the current state of this? How much is implemented, and how functional is it? |
|
@joshtriplett I've started work on it, and the syntax/parsing is in place, but the implementation currently does not work. I started working on Chalk, but that has stalled since I wasn't really able to know whether it was necessary for implementing it in rustc. I've also gotten a bit sidetracked working on other things. |
|
Is it planned to recognize Associated Constant Equality as disjoint cases? trait Foo{
const DECIDER: bool;
}
trait Bar{ /*stuff*/ }
impl<T: Foo<DECIDER = true>> Bar for T{ /*stuff*/ }
impl<T: Foo<DECIDER = false>> Bar for T{ /*stuff*/ } |
This comment was marked as resolved.
This comment was marked as resolved.
rustbot
added
the
F-associated_const_equality
|
@urben1680 I believe this would be the main point of this, but I have not got around to actually implementing it |
Replace the hard-coded macro implementing `Frame` for `[impl Sample;0-32]`, with a generic impl based on const-generics. I discovered the need for this, when trying to simplify some macro- -implementations in the `ebur128` crate with const-generics. We cannot remove the need for `NumChannels`, since (see reference 1) "Associated Const Equality" is not yet stable. We can however adapt the `NumChannels` strategy from `N1..N32` to a `NChannels<N>`-generic type. Some opportunities like removing `unsafe` from `zip_map`, remain out of reach due to pending stabilization of the standard library. 1: rust-lang/rust#92827
Replace the hard-coded macro implementing `Frame` for `[impl Sample;0-32]`, with a generic impl based on const-generics. I discovered the need for this, when trying to simplify some macro- -implementations in the `ebur128` crate with const-generics. We cannot remove the need for `NumChannels`, since (see reference 1) "Associated Const Equality" is not yet stable. We can however adapt the `NumChannels` strategy from `N1..N32` to a `NChannels<N>`-generic type. Some opportunities like removing `unsafe` from `zip_map`, remain out of reach due to pending stabilization of the standard library. 1: rust-lang/rust#92827
cc rust-lang/rust#92827 - would be nice to be able to ensure a generic event is absolutely 32 bytes in ConstantX11Size::X11_SIZE, it could be very easy to wreak havoc by accidentally having an incorrectly sized event in SendEvent.
This comment was marked as off-topic.
This comment was marked as off-topic.
workingjubilee
added
the
A-const-generics
|
Another use case would be checking tensor shapes. I hit this issue when compiling my code that constrains the shapes of input tensors to have the same dimensionality and/or rank. For example, dumb code like the below pub trait TensorShape1D {
const SHAPE: usize; // i.e. length
}
pub fn add<const L: usize, LEFT_TENSOR: TensorShape1D<SHAPE=L>, RIGHT_TENSOR: TensorShape1D<SHAPE=L>>(left: LEFT_TENSOR, right: RIGHT_TENSOR) {
todo!()
}Any two structs that implement Right now, I have to use |
|
Tracking issues have a tendency to become unmanageable. Please open a dedicated new issue and label it with
F-associated_const_equality
|
fmease
added
S-tracking-impl-incomplete
fmease
changed the title
The existing code panics if you try to decode a too-large checksum and it fails, which is definitely wrong. Fix this so that FieldVec::from_iter does not panic, allowing the "invalid residue" error to be constructed. There is also a panic when trying to correct too-large checksums. This is arguably permissible, since it's something that's detectable at compile time (though what would be even better is if this language would support telling the compiler to do this; see rust-lang/rust#92827 for more info). But remove it anyway.
This is a tracking issue for the experimental feature associated const equality brought up in #702561 (RFC pending).
The feature gate for the issue is
#![feature(associated_const_equality)].About experimental features
An experimental feature is one that has not yet had an RFC. The idea is to allow implementation work to proceed to better inform an upcoming RFC. Experimental features cannot be stabilized without first having an RFC. The existence of an experimental feature does not indicate lang team consensus that the feature is desirable, only that there is a problem that is worthy of being solved and that the idea has enough merit to consider exploring. See the lang team process page for more details.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
FIXME(associated_const_equality)Unresolved Questions
None so far.
Implementation history
Footnotes
Original proposal with support but no official RFC, but implementation delayed. ↩
Initial effort to implement which includes parsing and use of
termthroughout the codebase, but still lacking a complete implementation. ↩More thorough implementation which works for basic cases. This allowed for consts to actually be bound, more than just parsing them. ↩
The text was updated successfully, but these errors were encountered: