Implement associated constants #23606

quantheory · 2015-03-22T11:36:39Z

The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in f32, i8, and so on, or close to good enough.

There is still some significant functionality missing from this commit:

~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or resolve, but it's probably not hard to get working.~~
Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, check_static_recursion doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a T: Int type parameter and want to use <T>::ZERO). See Update RFC 195 to account for RFC 246. rfcs#865.
~~Unused associated consts don't seem to trigger the dead_code lint when they should. Probably easy to fix.~~

Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.

rust-highfive · 2015-03-22T11:36:45Z

r? @pcwalton

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

eddyb · 2015-03-22T14:13:11Z

🎉 This is great!
I'll be looking over the changes, but I'd rather have someone more knowledgeable (e.g. @nikomatsakis) with the latest advances in type-checking do the actual review.

eddyb · 2015-03-22T14:29:04Z

src/librustc/middle/const_eval.rs

+                                                ref_id: ast::NodeId)
+                                                -> Option<&'tcx Expr>
+{
+    let rcvr_substs = ty::node_id_item_substs(tcx, ref_id).substs;


So you're expecting substitutions to be there, which means this can't be used earlier...
But this is an ExprPath, isn't it? Which means that at least the <T as Trait>::CONST case could be handled here, if an astconv interface were provided.

That reminds me, I meant to check if it's possible to move const_eval and everything depending on it to rustc_typeck and integrate it properly.
Maybe this can all be done in a follow-up PR after the groundwork has been laid.

Good point; I'm not really sure. The traits code is probably the main bit that I don't understand as well as I should here, so here (and even more so in rustc_typeck::check::compare_method) there may be a couple of details that are just superstitiously copied.

One thing that concerns me is that maybe we could have a path like <<T>::U as Trait>::CONST or <[T; <U>::N] as Trait>::CONST (or the nested UFCS could be in the trait, too). The former is disallowed right now because <T>::U can't be used to refer to an associated type; I don't know if that ever will be allowed in the future. The latter is of course one of the things I don't have working yet, but it seems like it could be done.

As for moving const_eval to rustc_typeck, probably the main obstacle there is that rustc_trans uses it. It's kind of awkward because middle::const_eval and trans::consts kind of duplicate some of each others' logic, but the former is more broadly used. But I think that const_eval is doing some things wrong that are done right in trans::consts. E.g. in const_eval all floats are treated as f64, and compare_const_vals treats them as totally ordered.

quantheory · 2015-03-22T18:15:51Z

r? @nikomatsakis

nikomatsakis · 2015-03-23T14:26:41Z

Exciting. I'll take a look. I agree that the interplay of constants, type-checking, and traits is subtle-- it's going to wind up (I think) as a kind of best-effort thing in the end, though I'd like to see add some amount of reasoning for treating constants more "generically" and deferring the actual evaluation until trans when types are known. This is probably related to some refactoring I've been doing for doing better normalization, but anyway.

quantheory · 2015-03-24T04:22:11Z

@nikomatsakis

[...] I'd like to see add some amount of reasoning for treating constants more "generically" and deferring the actual evaluation until trans when types are known. This is probably related to some refactoring I've been doing for doing better normalization, but anyway.

I don't quite understand what you're saying. Certainly I'm interested in interaction between constants and types (note that I proposed rust-lang/rfcs#884, which is necessary, though far from sufficient, for some concrete applications I have in mind). Are you saying that you have a justification for deferring evaluation until trans, or that you want to know would I say about this? (I do think that such a change needs to happen, at least in some cases, but it's not directly relevant to this PR, I believe.)

huonw · 2015-03-24T04:31:15Z

though I'd like to see add some amount of reasoning for treating constants more "generically" and deferring the actual evaluation until trans when types are known

It seems this may lead to old-transmute like errors, where some constant evaluation that is only known in trans is invalid (e.g. depending how we handle it, overflow).

bors · 2015-03-24T21:01:34Z

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

quantheory · 2015-03-25T16:58:52Z

I have gotten match patterns working, though using associated consts in range patterns causes the same ICE as array sizes. (Actually, if we deferred checking that the lower bound is below the upper bound until check_match, I think that that would solve the issue, but some things need to get moved around for array sizes anyway, so I'm not sure if it's worth it.)

I will try to rebase today.

nikomatsakis · 2015-03-26T08:46:53Z

Are you saying that you have a justification for deferring evaluation until trans, or that you want to know would I say about this? (I do think that such a change needs to happen, at least in some cases, but it's not directly relevant to this PR, I believe.)

I wasn't really saying either of those things. Well, I do have justifications for potentially deferring evaluation until monomorphization -- e.g., type-checking [i32; X::LEN] -- but I wasn't suggesting it was relevant to this PR.

Anyway, sorry for the delay. I intend to review today (actually, yesterday, but a lot of stuff came up and I wound up away from my computer for much of the day).

nikomatsakis · 2015-03-26T08:47:22Z

It seems this may lead to old-transmute like errors, where some constant evaluation that is only known in trans is invalid (e.g. depending how we handle it, overflow).

I was assuming type-checking would be more conservative than trans, not less.

nikomatsakis · 2015-03-26T15:04:27Z

@quantheory

So I've been reading through and so far I'm enjoying what I read -- but one comment. We definitely want a feature-gate on this work before it can land! Can you add a feature-gate for defining a trait with an associated constant? (I think that's probably sufficient; we could add a feature-gate for referencing such a constant as well, but so long as we don't export any public interfaces that define them, that shouldn't be necessary.)

quantheory · 2015-03-26T19:08:17Z

@nikomatsakis

Done! The feature gate covers both traits and impls, since you can define an inherent associated const.

quantheory · 2015-03-27T08:25:05Z

Hmm, I fixed the last error to get a full make check working again, but it looks like Travis CI hit a glitch. 😞

bors · 2015-03-28T01:54:56Z

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

quantheory · 2015-03-29T18:04:04Z

Rebased. Hmm, is there a way to restart the Travis CI build?

bors · 2015-03-30T17:16:37Z

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

nikomatsakis · 2015-03-30T18:39:34Z

@quantheory cool, thanks. I read through most of the PR and didn't have any major comments, it all seemed quite nice. But then I got distracted again by the beta deadline and in particular researching and implementing rust-lang/rfcs#1023. Argh. I will look it over again today -- but now that there is a feature-gate, I feel pretty good about landing this before I understand every bit. We can improve over time.

quantheory · 2015-03-31T16:34:26Z

@nikomatsakis OK, cool. Just rebased!

nikomatsakis · 2015-04-01T09:44:06Z

OK, so I was doing some experimentation. I found that the following example ICEs:

// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

#![feature(associated_consts)]

use std::marker::MarkerTrait;

trait Foo: MarkerTrait {
    const ID: i32;
}

trait Bar: MarkerTrait {
    const ID: i32;
}

impl Foo for i32 {
    const ID: i32 = 1;
}

impl Bar for i32 {
    const ID: i32 = 3;
}

const X: i32 = <i32>::ID;

fn main() {
    assert_eq!(1, X);
}

the problem is not super deep, it's just that the "ambiguity reporting" code assumes methods.

nikomatsakis · 2015-04-01T09:48:40Z

So I'm basically ready to r+. I'm just wondering whether it makes sense to hold this till after the beta branch is cut this evening.

nikomatsakis · 2015-04-01T09:51:56Z

(Basically, I'm inclined to wait because it seems like landing this patch can only create merge conflicts and other uncertainty, and the feature is feature-gated anyhow. Landing all the critical PRs before the branch deadline is always challenging anyway.)

bors · 2015-04-01T14:42:58Z

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

bors · 2015-04-22T06:38:57Z

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

Introduces new variants and types in syntax::ast, middle::ty, and middle::def.

…ociated constants is not yet working.

…ated consts.

quantheory · 2015-04-25T05:13:43Z

@nikomatsakis bump

cristicbz · 2015-04-25T06:53:51Z

@quantheory try #rust-internals IRC?

nikomatsakis · 2015-04-27T14:01:39Z

@bors r+ p=1 4c0ac6d

Giving p=1 due to the fact that this has been hanging around. Thanks @quantheory for your persistence.

bors · 2015-04-27T14:01:40Z

📌 Commit 4c0ac6d has been approved by nikomatsakis

Closes #17841. The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough. There is still some significant functionality missing from this commit: - ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~ - Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet. - Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865. - ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~ Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.

bors · 2015-04-27T16:45:22Z

⌛ Testing commit 4c0ac6d with merge 857ef6e...

bors · 2015-04-27T18:46:47Z

☀️ 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

quantheory · 2015-04-27T22:14:53Z

🎉

petrochenkov · 2015-04-27T22:35:14Z

Congrats.
Now it's time to empty the "primitive" modules!

kvark · 2015-05-06T14:29:09Z

Thanks @quantheory, this is a huge boon for us!

burdges · 2016-10-12T04:12:59Z

Anyone considered replacing mem::size_of::<T>() with an associated constant, maybe part of the Sized trait or maybe not?

mitchmindtree · 2016-10-12T16:39:38Z

@burdges I think this is one of the examples given in the original RFC

rust-highfive assigned pcwalton Mar 22, 2015

eddyb reviewed Mar 22, 2015
View reviewed changes

rust-highfive assigned nikomatsakis and unassigned pcwalton Mar 22, 2015

quantheory force-pushed the associated_const branch 2 times, most recently from c6ca1b8 to e43afbc Compare March 25, 2015 17:24

quantheory force-pushed the associated_const branch from 69bf389 to 451c7b3 Compare March 29, 2015 17:43

quantheory force-pushed the associated_const branch from 451c7b3 to 00267eb Compare March 31, 2015 16:30

quantheory force-pushed the associated_const branch 2 times, most recently from d38d43f to 2cd6cd6 Compare April 17, 2015 06:36

quantheory added 8 commits April 23, 2015 21:02

Structural changes for associated constants

b549977

Introduces new variants and types in syntax::ast, middle::ty, and middle::def.

Functional changes for associated constants. Cross-crate usage of ass…

7129e88

…ociated constants is not yet working.

Fix a number of bugs that interfered with cross-crate usage of associ…

3d9b5d0

…ated consts.

Add previously omitted associated const tests.

7f78887

Fix dead code check for associated const impls.

91ae5e3

Get associated consts working in match patterns.

29eb550

Feature-gate associated constants.

b1db4ec

Remove obsolete "MarkerTrait" from tests.

4c0ac6d

quantheory force-pushed the associated_const branch from 2cd6cd6 to 4c0ac6d Compare April 25, 2015 04:59

bors merged commit 4c0ac6d into rust-lang:master Apr 27, 2015

This was referenced Apr 27, 2015

Rustdoc: ignore deref-inherited static methods #24657

Merged

syntax: Move ast_map into it's own crate #24757

Closed

Make a module out of debuginfo #24762

Merged

quantheory mentioned this pull request Apr 29, 2015

ICE on ambiguous associated const reference #24922

Closed

milibopp mentioned this pull request May 6, 2015

Use associated constants where applicable dimforge/nalgebra#123

Closed

Implement associated constants #23606

Implement associated constants #23606

Conversation

quantheory commented Mar 22, 2015

rust-highfive commented Mar 22, 2015

eddyb commented Mar 22, 2015

eddyb Mar 22, 2015

Choose a reason for hiding this comment

quantheory Mar 22, 2015

Choose a reason for hiding this comment

quantheory commented Mar 22, 2015

nikomatsakis commented Mar 23, 2015

quantheory commented Mar 24, 2015

huonw commented Mar 24, 2015

bors commented Mar 24, 2015

quantheory commented Mar 25, 2015

nikomatsakis commented Mar 26, 2015

nikomatsakis commented Mar 26, 2015

nikomatsakis commented Mar 26, 2015

quantheory commented Mar 26, 2015

quantheory commented Mar 27, 2015

bors commented Mar 28, 2015

quantheory commented Mar 29, 2015

bors commented Mar 30, 2015

nikomatsakis commented Mar 30, 2015

quantheory commented Mar 31, 2015

nikomatsakis commented Apr 1, 2015

nikomatsakis commented Apr 1, 2015

nikomatsakis commented Apr 1, 2015

bors commented Apr 1, 2015

bors commented Apr 22, 2015

quantheory commented Apr 25, 2015

cristicbz commented Apr 25, 2015

nikomatsakis commented Apr 27, 2015

bors commented Apr 27, 2015

bors commented Apr 27, 2015

bors commented Apr 27, 2015

quantheory commented Apr 27, 2015

petrochenkov commented Apr 27, 2015

kvark commented May 6, 2015

burdges commented Oct 12, 2016

mitchmindtree commented Oct 12, 2016