the basic strategy is to distinguish `mod foo;` from `mod foo {...}`
by checking if the span for the module item and module contents is
in different files. if it's the case, we prefer module contents.
it is technically possible to fix#12926 without changing the AST,
probably by checking the individual items' span. this is not without
a problem though, since it is possible that some items inside
`mod foo {...}` may have originated from other file (e.g. `include!`).
therefore it is better to record both spans explicitly.
I filed bugs #13734 and #13759 recently, and then realized I could probably fix them myself. This does exactly that, with a couple additional modifications and additions to the test-suite to pick up on that.
I've never done this before, so please feel free to tell me all the things I'm doing wrong or could be doing better.
this is useful when the module item and module contents are defined
from different files (like rustdoc). in most cases the original span
for the module item would be used; in other cases, the span for
module contents is available separately at the `inner` field.
It reflected the obsolete syntax `use a, b, c;` and did not make past the parser (though it was a non-fatal error so we can continue). This legacy affected many portions of rustc and rustdoc as well, so this PR cleans them up altogether.
As a side effect of cleanup, we now have `SCHEMA_VERSION` in `rustdoc::clean` (instead of the crate root), so it has a better chance to be updated when `rustdoc::clean` gets updated.
The underlying I/O objects implement a good deal of various options here and
there for tuning network sockets and how they perform. Most of this is a relic
of "whatever libuv provides", but these options are genuinely useful.
It is unclear at this time whether these options should be well supported or
not, or whether they have correct names or not. For now, I believe it's better
to expose the functionality than to not, but all new methods are added with
an #[experimental] annotation.
This addresses the ICE from #13763, but it does not allow the test to compile,
due to #13768. An alternate test was checked in in the meantime.
Closes#13763
it reflected the obsolete syntax `use a, b, c;` and did not make
past the parser (though it was a non-fatal error so we can continue).
this legacy affected many portions of rustc and rustdoc as well,
so this commit cleans them up altogether.
Before, tests for dynamic regexes ran during stage1 and tests for
native regexes ran during stage2. But the buildbots don't test stage1,
so now both dynamic and native tests are run during stage2.
Closes#13740.
Clarifies the interaction of `is_dir`, `is_file` and `exists` with
symbolic links. Adds a convenience `lstat` function alongside of
`stat`. Removes references to conditions.
Closes issue #12583.
Clarifies the interaction of `is_dir`, `is_file` and `exists` with
symbolic links. Adds a convenience `lstat` function alongside of
`stat`. Removes references to conditions.
Closes issue #12583.
This addresses the ICE from #13763, but it does not allow the test to compile,
due to #13768. An alternate test was checked in in the meantime.
Closes#13763
Before, tests for dynamic regexes ran during stage1 and tests for
native regexes ran during stage2. But the buildbots don't test stage1,
so now both dynamic and native tests are run during stage2.
Closes#13740.
Follow-up on issue #13297 and PR #13710. Instead of following the (confusing) C/C++ approach
of using `MIN_VALUE` for the smallest *positive* number, we introduce `MIN_POS_VALUE` (and
in the Float trait, `min_pos_value`) to represent this number.
This patch also removes a few remaining redundantly-defined constants that were missed last
time around.
It didn't work because it tried to call itself but symbols are not
exported as default in executables.
Note that `fun5` is not internal anymore since it is in library.
Second commit removes/updates some old tests.
It didn't work because it tried to call itself but symbols are not
exported as default in executables.
Note that `fun5` is not internal anymore since it is in library.
Implements [RFC 7](https://github.com/rust-lang/rfcs/blob/master/active/0007-regexps.md) and will hopefully resolve#3591. The crate is marked as experimental. It includes a syntax extension for compiling regexps to native Rust code.
Embeds and passes the `basic`, `nullsubexpr` and `repetition` tests from [Glenn Fowler's (slightly modified by Russ Cox for leftmost-first semantics) testregex test suite](http://www2.research.att.com/~astopen/testregex/testregex.html). I've also hand written a plethora of other tests that exercise Unicode support, the parser, public API, etc. Also includes a `regex-dna` benchmark for the shootout.
I know the addition looks huge at first, but consider these things:
1. More than half the number of lines is dedicated to Unicode character classes.
2. Of the ~4,500 lines remaining, 1,225 of them are comments.
3. Another ~800 are tests.
4. That leaves 2500 lines for the meat. The parser is ~850 of them. The public API, compiler, dynamic VM and code generator (for `regexp!`) make up the rest.
I decided to put architecture constants in another mod. They are not used, so a part of me is thinking of just getting rid of them altogether. The rest should be similar to what @brson wants.
Fixes#13536
