This PR is primarily motivated by (and fixes) #12926.
We currently only have a span for the individual item itself and not for the referred contents. This normally does not cause a problem since both are located in the same file; it *is* possible that the contained statement or item is located in the other file (the syntax extension can do that), but even in that case the syntax extension should be located in the same file as the item. The module item (i.e. `mod foo;`) is the only exception here, and thus warrants a special treatment.
Rustdoc would now 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'd prefer module contents over module item. There are alternative strategies, but as noted above we will have some corner cases if we don't record the contents span explicitly.
As of cc6ec8df, the Owned closures example uses println! instead of
debug!, making a note about seeing debug seem out-of-place in this
section.
Since debug! is not used elsewhere in the tutorial, remove the note
entirely.
Hello,
With the latest version of Rust, calling to the function [`std::io::standard_error()`](http://static.rust-lang.org/doc/master/std/io/fn.standard_error.html) succeeds only if the value of the argument is `EndOfFile`, `IoUnavailable` or `InvalidInput`. If the function is called with another value as argument, it fails without message.
Here is a piece of code that reproduces the problem:
```rust
use std::io::{standard_error,EndOfFile,FileNotFound,PermissionDenied};
fn main() {
println!("Error 1: {}", standard_error(EndOfFile)); // does not fail
println!("Error 2: {}", standard_error(FileNotFound)); // fails
println!("Error 3: {}", standard_error(PermissionDenied)); //fails
}
```
This was because the `IoErrorKind` passed as argument wasn't matched against all the possible values.
I added the missing branches in the `match` statement inside the function, and i removed the call to the `fail!()` macro. I rebuilt the crate with the latest `rustc` version and it seems to works.
As of cc6ec8df, the Owned closures example uses println! instead of
debug!, making a note about seeing debug seem out-of-place in this
section.
Since debug! is not used elsewhere in the tutorial, remove the note
entirely.
Just modified the documentation for parse_bytes to make it more clear how the bytes were parsed (big endian) and to show an example of what it returned. I also added documentation for the to_str_bytes which previously had no documentation (besides one stackoverflow post).
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.
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.
