-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
The fix is straight-forward, but there are several changes while fixing the issue. 1) disallow `mut` keyword when making a new struct In code base, there are following code, struct Foo { mut a: int }; let a = Foo { mut a: 1 }; This is because of structural record, which is deprecated corrently (see issue rust-lang#3089) In structural record, `mut` keyword should be allowd to control mutability. But without structural record, we don't need to allow `mut` keyword while constructing struct. 2) disallow structural records in parser level This is related to 1). With structural records, there is an ambiguity between empty block and empty struct To solve the problem, I change parser to stop parsing structural records. I think this is not a problem, because structural records are not compiled already. Misc. issues There is an ambiguity between empty struct vs. empty match stmt. with following code, match x{} {} Two interpretation is possible, which is listed blow match (x{}) {} // matching with newly-constructed empty struct (match x{}) {} // matching with empty enum(or struct) x // and then empty block It seems that there is no such code in rust code base, but there is one test which uses empty match statement: https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs All other cases could be distinguished with look-ahead, but this can't be. One possible solution is wrapping with parentheses when matching with an uninhabited type. enum what { } fn match_with_empty(x: what) -> ~str { match (x) { //use parentheses to remove the ambiguity } }
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,7 @@ enum what { } | |
|
||
fn what_to_str(x: what) -> ~str | ||
{ | ||
match x { | ||
match (x) { | ||
} | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
// Copyright 2013 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. | ||
|
||
|
||
|
||
// -*- rust -*- | ||
struct Foo { | ||
} | ||
|
||
|
||
pub fn main() { | ||
let _foo = Foo{}; | ||
} |
2 comments
on commit 759702f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice work and much appreciated.
However, I am not sure if your approach to resolving the parser ambiguity is the right one. My personal preference is to say that struct literals cannot appear as match expressions without parentheses (I would say the same thing about following a do
; I'm not 100% sure what our rules are there). This is not quite the solution you opted for. I guess this should be discussed at a core team meeting, since this is very much a user-visible thing.
My personal opinion is that it surprises me that match x {}
would not parse and I'd rather that match x {}
parses than match Foo {} {}
or match Foo { x: y } { Foo { x: y } => { ... } }
, which are hard to read and which strike me as rather unlikely to occur in practice. If we say that no struct literals can appear as the discriminant of a match, we can also easily report a clear error ("use parentheses" for that case). I'm not sure that empty struct literals even make any sense, perhaps struct Foo {}
should be written struct Foo;
and handled like an empty enum variant (that is, a nullary constant).
How we choose to resolve this ambiguity also clearly affects how much lookahead we require (though perhaps not in the theoretical sense, if we were to refactor our grammar enough).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Incidentally, I might be inclined to just merge what you've done and file a follow-up issue to decide how best to resolve the parser ambiguities in this case and others...)
this looks like a merge failure. the code to parse capture clauses was removed I believe? not sure why you'd be adding it back in as part of this patch.