Skip to content

Parse fully-qualified associated types in generics without whitespace #20154

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 3, 2015

Conversation

ftxqxd
Copy link
Contributor

@ftxqxd ftxqxd commented Dec 23, 2014

This modifies Parser::eat_lt to always split up <<s, instead of doing so only when a lifetime name followed or the force parameter (now removed) was true. This is because Foo<<TYPE is now a valid start to a type, whereas previously only Foo<<LIFETIME was valid.

This is a [breaking-change]. Change code that looks like this:

let x = foo as bar << 13;

to use parentheses, like this:

let x = (foo as bar) << 13;

Closes #17362.

@ftxqxd ftxqxd force-pushed the qualified-assoc-type-generics branch from bcf5544 to 494fafc Compare December 25, 2014 05:26
This breaks code that looks like this:

    let x = foo as bar << 13;

Change such code to look like this:

    let x = (foo as bar) << 13;

Closes rust-lang#17362.

[breaking-change]
@nikomatsakis
Copy link
Contributor

I took the liberty of editing the PR message to include the all important "[breaking-change]" tag.

@nikomatsakis
Copy link
Contributor

Oh, I see it's in the commit. Oh well.

@nikomatsakis
Copy link
Contributor

I wonder if there is a way for us to give a nicer error message when things go wrong.

@ftxqxd
Copy link
Contributor Author

ftxqxd commented Jan 3, 2015

I’ve thought previously about some kind of process after/during tokenisation (but before parsing) that would look for certain patterns of tokens that look like they could be this sort of subtle syntactical problem; e.g., in this case it would look for a sequence like as [short sequence of tokens] <<. It would print a message later if there was a parsing error (or maybe any kind of error) during compilation, but otherwise be silent. That sort of thing could perhaps also detect things like foo<int>() as well.

bors added a commit that referenced this pull request Jan 3, 2015
…nikomatsakis

This modifies `Parser::eat_lt` to always split up `<<`s, instead of doing so only when a lifetime name followed or the `force` parameter (now removed) was `true`. This is because `Foo<<TYPE` is now a valid start to a type, whereas previously only `Foo<<LIFETIME` was valid.

This is a [breaking-change]. Change code that looks like this:

```rust
let x = foo as bar << 13;
```

to use parentheses, like this:

```rust
let x = (foo as bar) << 13;
```

Closes #17362.
@bors bors merged commit d9769ec into rust-lang:master Jan 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Qualified associated type in generic parameter needs a space separating the <<
3 participants