Skip to content
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

Model lexer doesn't handle range correctly #15877

Closed
emberian opened this issue Jul 21, 2014 · 1 comment
Closed

Model lexer doesn't handle range correctly #15877

emberian opened this issue Jul 21, 2014 · 1 comment

Comments

@emberian
Copy link
Member

0..2 is

[@0,0:1='0.',<45>,1:0]
[@1,2:2='.',<25>,1:2]
[@2,3:3='2',<44>,1:3]
[@3,4:4='\n',<52>,1:4]
[@4,5:4='<EOF>',<-1>,2:5]

Should be LIT_INTEGER(0) DOTDOT LIT_INTEGER(2)

@emberian
Copy link
Member Author

Another problem: 3.b()

fhahn added a commit to fhahn/rust that referenced this issue Dec 29, 2014
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 30, 2014
This patch for rust-lang#15877 uses Antlr's input lookahead (`_input.LA(1) != '.'`) to solve the conflict between the LIT_FLOAT and the range syntax.

Note that in order to execute the grammar tests, rust-lang#20245 should land first.
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 31, 2014
This patch resolves the second problem mentioned in rust-lang#15877: function calls to integers, e.g. `3.b()`.

 It does so, by checking whether the character following the first dot of a FLOAT_LIT is a character or an underscore (these should denote a valid identifier). This does not look like a particularly, but it seems like a lookahead of 1 is needed for this distinction.

Another interesting aspect are ranges that start with a integer constant, but end with a function call, e.g. `1..b()`. Rust treats this as a range from 1 to `b()`, but given that `1.` is a valid FLOAT_LIT, `1..b()` could be a function call to a float as well.

cc @cmr
@bors bors closed this as completed in b41a24f Dec 31, 2014
lnicola pushed a commit to lnicola/rust that referenced this issue Jan 3, 2024
Don't trim trailing whitespace from doc comments

Don't trim trailing whitespace from doc comments as multiple trailing spaces indicates a hard line break in Markdown.

I'd have liked to add a unit test for `docs_from_attrs`, but couldn't find a reasonable way to get an `&Attrs` object for use in the test.

Fixes rust-lang#15877.
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

No branches or pull requests

1 participant