Added support for partial type hints (`Foo<_>`). #12764

Kimundi · 2014-03-08T15:21:56Z

Summary

This patch introduces the _ token into the type grammar, with the meaning "infer this type".
With this change, the following two lines become equivalent:

let x = foo();
let x: _ = foo();

But due to its composability, it enables partial type hints like this:

let x: Bar<_> = baz();

Using it on the item level is explicitly forbidden, as the Rust language does not enable global type inference by design.

This implements the feature requested in #9508.

Things requiring clarification

The change to enable it is very small, but I have only limited understanding of the related code, so the approach here might be wrong.
- In particular, while this patch works, it does so in a way not originally intended according to the code comments.
This probably needs more tests, or rather feedback for which tests are still missing.
I'm unsure how this interacts with lifetime parameters, and whether it is correct in regard to them.
Partial type hints on the right side of as like &foo as *_ work in both a normal function contexts and in constexprs like static foo: *int = &'static 123 as *_. The question is whether this should be allowed in general.

Todo for this PR

The manual and tutorial still needs updating.

Bugs I'm unsure how to fix

Requesting inference for the top level of the right hand side of a as fails to infer correctly, even if all possible hints are given:

.../type_hole_1.rs:35:18: 35:22 error: the type of this value must be known in this context
.../type_hole_1.rs:35     let a: int = 1u32 as _;
                                       ^~~~

huonw · 2014-03-08T15:37:55Z

cc @nikomatsakis

Also there's a comment on the TyInfer variant declaration in syntax::ast that needs to be updated with this change (specifically, TyInfer is now allowed in places other than the top level of a type).

flaper87 · 2014-03-08T19:37:42Z

I agree it should be discussed further. Quite useful thing to have and a rather small change required.

I'd like to see the changes in the docs as part of this PR or at least an issue created to keep track of it.

ktt3ja · 2014-03-09T01:58:08Z

src/test/compile-fail/global_inference.rs

+
+    fn fn_test8(_f: fn() -> _) { }
+    //~^ ERROR type inference is not allowed on items
+}


Just wondering, is type hint allowed on method?

ktt3ja · 2014-03-09T02:07:41Z

Maybe adding a compile-fail test for the case when type hint is completely wrong would be good, too.

pcwalton · 2014-03-11T22:38:35Z

This has been agreed upon.

pcwalton · 2014-03-11T22:39:01Z

src/librustc/middle/typeck/collect.rs

@@ -132,7 +132,8 @@ impl AstConv for CrateCtxt {
    }

    fn ty_infer(&self, span: Span) -> ty::t {
-        self.tcx.sess.span_bug(span, "found `ty_infer` in unexpected place");
+        self.tcx.sess.span_err(span, "type inference is not allowed on items");


Can you make this more specific? Not everyone will know "type inference" means _.

erickt · 2014-03-12T18:32:36Z

cc-ing #10448, which talks about adding type hints for top-level items.

huonw · 2014-03-13T03:19:16Z

GHC got a very proposal recently: http://www.haskell.org/pipermail/ghc-devs/2014-March/004239.html

flaper87 · 2014-03-13T08:42:21Z

src/libsyntax/parse/parser.rs

@@ -1273,6 +1273,10 @@ impl Parser {
                bounds
            } = self.parse_path(LifetimeAndTypesAndBounds);
            TyPath(path, bounds, ast::DUMMY_NODE_ID)
+        } else if self.token == token::UNDERSCORE {


you can use self.eat(&token::UNDERSCORE) and remove the self.bump

Kimundi · 2014-03-13T11:45:32Z

That GHC proposal is very interesting, especially the generalizations and extensions listed there. Though I don't think we'll need anything more fancy than what is implemented here for a while.

nikomatsakis · 2014-03-14T02:54:22Z

Note: although I did r+, it is... mildly unclear to me if _ should be permitted in as expressions at all. It seems strange to cast without saying what you're casting to. But I guess it's useful to be able to partially say what you're casting to. Well, we can tweak this detail as we feel.

Kimundi · 2014-03-14T09:41:36Z

@nikomatsakis Hm, I personally did not see why let x = y as Z should not be seen as a build in function let x = cast::<_, Z>(y), so I expected it to work with this change.

@pnkfelix That indeed looks like a legitimate failure. I had trouble with my build environment the last few days that prevented me from simply running make check. (unrelated debug info test failures that I couldn't probably analysis till now)

I though I had run all relevant test suites manually, but it seems I forgot about the pretty printer, sorry. Now that I see the error, its obvious to me that it would happen. :)

nikomatsakis · 2014-03-14T11:19:00Z

@Kimundi Good point. The reason that the type check doesn't work is because we check immediately that the as conversion is legal. We could just say that the type of <expr> as T is T and then go back and check later that the type conversion is legal once types are known. I kind of like that. Clearly a separable task though.

eddyb · 2014-03-14T12:50:13Z

@nikomatsakis I did mention the same approach on IRC whenever someone wanted to fix as, but I guess they never got that far. It would fix some nasty cases in closures, where you need to annotate everything.

inference in a type with `_` ). This enables partial type inference.

# Summary This patch introduces the `_` token into the type grammar, with the meaning "infer this type". With this change, the following two lines become equivalent: ``` let x = foo(); let x: _ = foo(); ``` But due to its composability, it enables partial type hints like this: ``` let x: Bar<_> = baz(); ``` Using it on the item level is explicitly forbidden, as the Rust language does not enable global type inference by design. This implements the feature requested in #9508. # Things requiring clarification - The change to enable it is very small, but I have only limited understanding of the related code, so the approach here might be wrong. - In particular, while this patch works, it does so in a way not originally intended according to the code comments. - This probably needs more tests, or rather feedback for which tests are still missing. - I'm unsure how this interacts with lifetime parameters, and whether it is correct in regard to them. - Partial type hints on the right side of `as` like `&foo as *_` work in both a normal function contexts and in constexprs like `static foo: *int = &'static 123 as *_`. The question is whether this should be allowed in general. # Todo for this PR - The manual and tutorial still needs updating. # Bugs I'm unsure how to fix - Requesting inference for the top level of the right hand side of a `as` fails to infer correctly, even if all possible hints are given: ``` .../type_hole_1.rs:35:18: 35:22 error: the type of this value must be known in this context .../type_hole_1.rs:35 let a: int = 1u32 as _; ^~~~ ```

Remove deprecate action https://old.reddit.com/r/rust/comments/vyx4oj/actionsrs_organization_became_unmaintained/ Looking at this holistically, I don't fully understand *why* we need an action here? Seems like we can just use rustup? nowadays github runners come with rustup pre-installed.

`significant_drop_in_scrutinee`: Fix false positives due to false drops of place expressions Place expressions do not really create temporaries, so they will not create significant drops. For example, the following code snippet is quite good (rust-lang#8963): ```rust fn main() { let x = std::sync::Mutex::new(vec![1, 2, 3]); let x_guard = x.lock().unwrap(); match x_guard[0] { 1 => println!("1!"), x => println!("{x}"), } drop(x_guard); // Some "usage" } ``` Also, the previous logic thinks that references like `&MutexGuard<_>`/`Ref<'_, MutexGuard<'_, _>>` have significant drops, which is simply not true, so it is fixed together in this PR. Fixes rust-lang/rust-clippy#8963 Fixes rust-lang/rust-clippy#9072 changelog: [`significant_drop_in_scrutinee`]: Fix false positives due to false drops of place expressions. r? `@blyxyas`

ktt3ja reviewed Mar 9, 2014
View reviewed changes

pcwalton reviewed Mar 11, 2014
View reviewed changes

flaper87 reviewed Mar 13, 2014
View reviewed changes

Added support for type placeholders (explicit requested type

eb69eb3

inference in a type with `_` ). This enables partial type inference.

bors closed this Mar 14, 2014

bors merged commit eb69eb3 into rust-lang:master Mar 14, 2014

alexcrichton mentioned this pull request Mar 14, 2014

support partial type hints #9508

Closed

Kimundi mentioned this pull request Mar 14, 2014

Mention type placeholders in the manual and tutorial #12891

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added support for partial type hints (`Foo<_>`). #12764

Added support for partial type hints (`Foo<_>`). #12764

Kimundi commented Mar 8, 2014

huonw commented Mar 8, 2014

flaper87 commented Mar 8, 2014

ktt3ja Mar 9, 2014

ktt3ja commented Mar 9, 2014

pcwalton commented Mar 11, 2014

pcwalton Mar 11, 2014

erickt commented Mar 12, 2014

huonw commented Mar 13, 2014

flaper87 Mar 13, 2014

Kimundi commented Mar 13, 2014

nikomatsakis commented Mar 14, 2014

Kimundi commented Mar 14, 2014

nikomatsakis commented Mar 14, 2014

eddyb commented Mar 14, 2014

Added support for partial type hints (Foo<_>). #12764

Added support for partial type hints (Foo<_>). #12764

Conversation

Kimundi commented Mar 8, 2014

Summary

Things requiring clarification

Todo for this PR

Bugs I'm unsure how to fix

huonw commented Mar 8, 2014

flaper87 commented Mar 8, 2014

ktt3ja Mar 9, 2014

Choose a reason for hiding this comment

ktt3ja commented Mar 9, 2014

pcwalton commented Mar 11, 2014

pcwalton Mar 11, 2014

Choose a reason for hiding this comment

erickt commented Mar 12, 2014

huonw commented Mar 13, 2014

flaper87 Mar 13, 2014

Choose a reason for hiding this comment

Kimundi commented Mar 13, 2014

nikomatsakis commented Mar 14, 2014

Kimundi commented Mar 14, 2014

nikomatsakis commented Mar 14, 2014

eddyb commented Mar 14, 2014

Added support for partial type hints (`Foo<_>`). #12764

Added support for partial type hints (`Foo<_>`). #12764