| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This adds a new lexer/parser combo for the entire Rust language can be generated with with flex and bison, taken from my project at https://github.com/bleibig/rust-grammar. There is also a testing script that runs the generated parser with all *.rs files in the repository (except for tests in compile-fail or ones that marked as "ignore-test" or "ignore-lexer-test"). If you have flex and bison installed, you can run these tests using the new "check-grammar" make target.
This does not depend on or interact with the existing testing code in the grammar, which only provides and tests a lexer specification.
OS X users should take note that the version of bison that comes with the Xcode toolchain (2.3) is too old to work with this grammar, they need to download and install version 3.0 or later.
The parser builds up an S-expression-based AST, which can be displayed by giving the "-v" argument to parser-lalr (normally it only gives output on error). It is only a rough approximation of what is parsed and doesn't capture every detail and nuance of the program.
Hopefully this should be sufficient for issue #2234, or at least a good starting point.
|
|
Per [RFC 517](https://github.com/rust-lang/rfcs/pull/575/), this commit introduces platform-native strings. The API is essentially as described in the RFC.
The WTF-8 implementation is adapted from @SimonSapin's [implementation](https://github.com/SimonSapin/rust-wtf8). To make this work, some encodign and decoding functionality in `libcore` is now exported in a "raw" fashion reusable for WTF-8. These exports are *not* reexported in `std`, nor are they stable.
|
|
Per [RFC 517](https://github.com/rust-lang/rfcs/pull/575/), this commit
introduces platform-native strings. The API is essentially as described
in the RFC.
The WTF-8 implementation is adapted from @SimonSapin's
[implementation](https://github.com/SimonSapin/rust-wtf8). To make this
work, some encodign and decoding functionality in `libcore` is now
exported in a "raw" fashion reusable for WTF-8. These exports are *not*
reexported in `std`, nor are they stable.
|
|
First commit is mindless groundwork for the second one, to make the spans (arguably) nicer.
### before
```
require-parens-for-chained-comparison.rs:14:20: 14:22 error: Chained comparison operators require parentheses
require-parens-for-chained-comparison.rs:14 false == false == false;
^~
require-parens-for-chained-comparison.rs:17:16: 17:17 error: Chained comparison operators require parentheses
require-parens-for-chained-comparison.rs:17 false == 0 < 2;
^
require-parens-for-chained-comparison.rs:20:8: 20:9 error: Chained comparison operators require parentheses
require-parens-for-chained-comparison.rs:20 f<X>();
^
require-parens-for-chained-comparison.rs:20:8: 20:9 help: Use ::< instead of < if you meant to specify type arguments.
require-parens-for-chained-comparison.rs:20 f<X>();
^
```
### after
```
require-parens-for-chained-comparison.rs:14:11: 14:22 error: chained comparison operators require parentheses
require-parens-for-chained-comparison.rs:14 false == false == false;
^~~~~~~~~~~
require-parens-for-chained-comparison.rs:17:11: 17:17 error: chained comparison operators require parentheses
require-parens-for-chained-comparison.rs:17 false == 0 < 2;
^~~~~~
require-parens-for-chained-comparison.rs:20:6: 20:9 error: chained comparison operators require parentheses
require-parens-for-chained-comparison.rs:20 f<X>();
^~~
require-parens-for-chained-comparison.rs:20:6: 20:9 help: use `::<...>` instead of `<...>` if you meant to specify type arguments
require-parens-for-chained-comparison.rs:20 f<X>();
^~~
```
|
|
Lower case and give a more precise span: from operator to operator, not
just the last one.
|
|
|
|
... so that `super::foo` gets serialized as `super:: foo`, rather than `super :: foo`.
|
|
r? @alexcrichton
Part of #20792 that wasn't done in your commit.
|
|
The regex library was largely used for non-critical aspects of the compiler and
various external tooling. The library at this point is duplicated with its
out-of-tree counterpart and as such imposes a bit of a maintenance overhead as
well as compile time hit for the compiler itself.
The last major user of the regex library is the libtest library, using regexes
for filters when running tests. This removal means that the filtering has gone
back to substring matching rather than using regexes.
|
|
This is not used in-tree and is available out-of-tree
|
|
|
|
I think this is all of the remaining code to be removed. Let me know if I've missed anything.
Closes #19145
|
|
Specifically:
* Peekable
* ByRef
* Skip
* Take
* Fuse
Fixes #20547
|
|
|
|
|
|
|
|
This PR is intended as alternative to #20958. It fixes the same grammar inconsistencies, but does not increase the operator precedence of `..`, leaving it at the same level as the assignment operator.
For previous discussion, see #20811 and #20958.
Grammar changes:
* allow `for _ in 1..i {}` (fixes #20241)
* allow `for _ in 1.. {}` as infinite loop
* prevent use of range notation in contexts where only operators of high precedence are expected (fixes #20811)
Parser code cleanup:
* remove `RESTRICTION_NO_DOTS`
* make `AS_PREC` const and follow naming convention
* make `min_prec` inclusive
r? nikomatsakis
|
|
This pull request add tooltips to most links of sidebar.
The tooltips display "summary line" of items' document.
Some lengthy/annoying raw markdown code are eliminated, such as links and headers.
- `[Rust](http://rust-lang.org)` displays as `Rust` (no URLs)
- `# header` displays as `header` (no `#`s)
Some inline spans, e.g. ``` `code` ``` and ```*emphasis*```, are kept as they are, for better readable.
I've make sure `&` `'` `"` `<` and `>` are properly displayed in tooltips, for example, `&'a Option<T>`.
Online preview: http://liigo.com/tmp/tooltips/std/index.html
@alexcrichton @steveklabnik since you have reviewed my previous ([v1](https://github.com/rust-lang/rust/pull/13014),[v2](https://github.com/rust-lang/rust/pull/16448)) PRs of this serise, which have been closed for technical reasons. Thank you.
|
|
exported macros.
Fixes issue #20701
|
|
There are doc improvements as well as these conversions:
- int/uint -> isize/usize
- u/i -> us/is
|
|
Lifetime elision documentation was reference a previously existing function
that doesn't exist. After talking with Steve Klabnik, I confirmed the correct
function to be referenced and updated documentation accordingly.
|
|
|
|
When I wrote this code, my janky shim to verify the constants didn't
work as intended.
This fixes everything I've run into since merge, which is hopefully
everything.
|
|
Make compiletest set an environment variable so that on Windows 32-bit test executables containing certain substrings (e.g. 'install', 'setup', 'update', 'patch') are not blocked by UAC's Installer Detection Technology.
|
|
|
|
Fixes #21430
|
|
Fixes #21440"
|
|
Fixes #21469.
|
|
This should fix issue #20797 (but I don't want to close it automatically).
As the actual fix is very small this would be a perfect candidate for a rollup.
|
|
Compiling won't produce an executable just yet because (as stated in the next
paragraph) there are errors. By removing this sentance, the reader won't get
confused when they expect a successful compile i.e. if they don't read ahead one
paragraph, they are going to be checking their code and wondering why it's not
compiling.
|
|
Updated incorrect error messages, and removed explicit return statements from example code.
|
|
Previous wording wasn’t clear about its actual behaviour. It could be
interpreted as answering either:
* Can current thread panic?
* Is current thread unwinding because of panic?
r? @steveklabnik
|
|
Not sure on what *exactly* should be said here, but I think this is the most important bit. This PR also establishes conventions for describing performance minimally.
I suggest to describe preformance for individual methods we use a `# Performance` heading. Not sure if we should have
```
# Performance: O(1)
details details
```
or
```
# Performance:
O(1)
details details
```
Since I think most methods don't need discussion, the former seems more resonable. But it's kind of weird to have info "in" the heading.
r? @steveklabnik
|
|
Fixes #6444
I need some help with the macro docs here, as I couldn't figure it out. @kmcallister @eddyb or someone else?
|
|
When we moved over to the book, we lost this.
|
|
Fixes #6444
|
|
|
|
Grammar changes:
* allow 'for _ in 1..i {}' (fixes #20241)
* allow 'for _ in 1.. {}' as infinite loop
* prevent use of range notation in contexts where only operators of high
precedence are expected (fixes #20811)
Parser code cleanup:
* remove RESTRICTION_NO_DOTS
* make AS_PREC const and follow naming convention
* make min_prec inclusive
|
|
When we moved over to the book, we lost this.
|
|
|
|
* Include an illustration of a function that accepts two closures.
|
|
rebase and fix of #19267
|
|
|
|
|
|
|
|
|
|
When I wrote this code, my janky shim to verify the constants didn't
work as intended.
This fixes everything I've run into since merge, which is hopefully
everything.
|
|
|
|
executables containing certain substrings (e.g. 'install', 'setup', 'update', 'patch') are not blocked by UAC's Installer Detection Technology.
|
|
ByRef is not tested included because it is a trivial pass through.
|
