| Age | Commit message (Collapse) | Author | Lines |
|---|
|
[breaking-change]
|
|
|
|
|
|
Closes #14303.
|
|
Most errors that arise in the lexer can be recovered from. This allows
for more than one syntax error to be reported at a time.
|
|
Closes #14303.
|
|
These have all been deprecated for awhile now, so it's likely time to start removing them.
|
|
All of these features have been obsolete since February 2014, where most have
been obsolete since 2013. There shouldn't be any more need to keep around the
parser hacks after this length of time.
|
|
The span on a inner doc-comment would point to the next token, e.g. the span for the `a` line points to the `b` line, and the span of `b` points to the `fn`.
```rust
//! a
//! b
fn bar() {}
```
|
|
[breaking-change]
|
|
|
|
|
|
The position of the .bump call (before extracting the span fields) was
causing a doc-comment to have the span of the next token, not itself.
|
|
Closes #6449
|
|
This is an implementation of RFC 16. A module can now only be loaded if the
module declaring `mod name;` "owns" the current directory. A module is
considered as owning its directory if it meets one of the following criteria:
* It is the top-level crate file
* It is a `mod.rs` file
* It was loaded via `#[path]`
* It was loaded via `include!`
* The module was declared via an inline `mod foo { ... }` statement
For example, this directory structure is now invalid
// lib.rs
mod foo;
// foo.rs
mod bar;
// bar.rs;
fn bar() {}
With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be
renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`,
and can only be accessed through `foo`.
RFC: 0016-module-file-system-hierarchy
Closes #14180
[breaking-change]
|
|
This is an implementation of RFC 16. A module can now only be loaded if the
module declaring `mod name;` "owns" the current directory. A module is
considered as owning its directory if it meets one of the following criteria:
* It is the top-level crate file
* It is a `mod.rs` file
* It was loaded via `#[path]`
* It was loaded via `include!`
* The module was declared via an inline `mod foo { ... }` statement
For example, this directory structure is now invalid
// lib.rs
mod foo;
// foo.rs
mod bar;
// bar.rs;
fn bar() {}
With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be
renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`,
and can only be accessed through `foo`.
RFC: 0016-module-file-system-hierarchy
Closes #14180
[breaking-change]
|
|
Had to make `struct Tm` in `libtime` not serializable for now.
|
|
1. Wherever the `buf` field of a `Formatter` was used, the `Formatter` is used
instead.
2. The usage of `write_fmt` is minimized as much as possible, the `write!` macro
is preferred wherever possible.
3. Usage of `fmt::write` is minimized, favoring the `write!` macro instead.
|
|
This adds the flag --color, which allows the user to force coloring or
turn it off. The default behavior stays the same as before (colorize, if
output goes to tty).
Why this is beneficial is explained in issue #12881.
Please note that this commit doesn't include any regression tests. I
thought about how I'd write a test for this and it doesn't seem to be
worth the effort to me for a UI change like this.
Fixes #12881.
|
|
This uses the trick of replacing the << token with a < token to parse closure
types correctly.
Closes #13324
|
|
Integers are always parsed as a u64 in libsyntax, but they're stored as i64. The
parser and pretty printer both printed an i64 instead of u64, sometimes
introducing an extra negative sign.
|
|
* Added `// no-pretty-expanded` to pretty-print a test, but not run it through
the `expanded` variant.
* Removed #[deriving] and other expanded attributes after they are expanded
* Removed hacks around &str and &&str and friends (from both the parser and the
pretty printer).
* Un-ignored a bunch of tests
|
|
|
|
|
|
This commit revisits the `cast` module in libcore and libstd, and scrutinizes
all functions inside of it. The result was to remove the `cast` module entirely,
folding all functionality into the `mem` module. Specifically, this is the fate
of each function in the `cast` module.
* transmute - This function was moved to `mem`, but it is now marked as
#[unstable]. This is due to planned changes to the `transmute`
function and how it can be invoked (see the #[unstable] comment).
For more information, see RFC 5 and #12898
* transmute_copy - This function was moved to `mem`, with clarification that is
is not an error to invoke it with T/U that are different
sizes, but rather that it is strongly discouraged. This
function is now #[stable]
* forget - This function was moved to `mem` and marked #[stable]
* bump_box_refcount - This function was removed due to the deprecation of
managed boxes as well as its questionable utility.
* transmute_mut - This function was previously deprecated, and removed as part
of this commit.
* transmute_mut_unsafe - This function doesn't serve much of a purpose when it
can be achieved with an `as` in safe code, so it was
removed.
* transmute_lifetime - This function was removed because it is likely a strong
indication that code is incorrect in the first place.
* transmute_mut_lifetime - This function was removed for the same reasons as
`transmute_lifetime`
* copy_lifetime - This function was moved to `mem`, but it is marked
`#[unstable]` now due to the likelihood of being removed in
the future if it is found to not be very useful.
* copy_mut_lifetime - This function was also moved to `mem`, but had the same
treatment as `copy_lifetime`.
* copy_lifetime_vec - This function was removed because it is not used today,
and its existence is not necessary with DST
(copy_lifetime will suffice).
In summary, the cast module was stripped down to these functions, and then the
functions were moved to the `mem` module.
transmute - #[unstable]
transmute_copy - #[stable]
forget - #[stable]
copy_lifetime - #[unstable]
copy_mut_lifetime - #[unstable]
[breaking-change]
|
|
|
|
|
|
This commit brings the local_data api up to modern rust standards with a few key
improvements:
* All functionality is now exposed as a method on the keys themselves. Instead
of importing std::local_data, you now use "key.set()" and "key.get()".
* All closures have been removed in favor of RAII functionality. This means that
get() and get_mut() no long require closures, but rather return
Option<SmartPointer> where the smart pointer takes care of relinquishing the
borrow and also implements the necessary Deref traits
* The modify() function was removed to cut the local_data interface down to its
bare essentials (similarly to how RefCell removed set/get).
[breaking-change]
|
|
This commit brings the local_data api up to modern rust standards with a few key
improvements:
* The `pop` and `set` methods have been combined into one method, `replace`
* The `get_mut` method has been removed. All interior mutability should be done
through `RefCell`.
* All functionality is now exposed as a method on the keys themselves. Instead
of importing std::local_data, you now use "key.replace()" and "key.get()".
* All closures have been removed in favor of RAII functionality. This means that
get() and get_mut() no long require closures, but rather return
Option<SmartPointer> where the smart pointer takes care of relinquishing the
borrow and also implements the necessary Deref traits
* The modify() function was removed to cut the local_data interface down to its
bare essentials (similarly to how RefCell removed set/get).
[breaking-change]
|
|
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes #10025
[breaking-change]
|
|
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
r? @brson or @alexcrichton or whoever
|
|
Lots of assorted things here and there, all the details are in the commits.
Closes #11712
|
|
for `~str`/`~[]`.
Note that `~self` still remains, since I forgot to add support for
`Box<self>` before the snapshot.
How to update your code:
* Instead of `~EXPR`, you should write `box EXPR`.
* Instead of `~TYPE`, you should write `Box<Type>`.
* Instead of `~PATTERN`, you should write `box PATTERN`.
[breaking-change]
|
|
Previously, the parser would not allow you to simultaneously implement a
function with a different abi as well as being unsafe at the same time. This
extends the parser to allow functions of the form:
unsafe extern fn foo() {
// ...
}
The closure type grammar was also changed to reflect this reversal, types
previously written as "extern unsafe fn()" must now be written as
"unsafe extern fn()". The parser currently has a hack which allows the old
style, but this will go away once a snapshot has landed.
Closes #10025
[breaking-change]
|
|
Also updated the comment for `parse_inner_attrs_and_next` and removed extra whitespace on line endings.
|
|
r? @alexcrichton
|
|
This is needed to bootstrap fix for #5723.
|
|
comments.
|
|
lists. This is needed to bootstrap fix for #5723.
|
|
The outer attributes were manually appended when a module file was parsed, but
the attributes were also added higher up the stack of parsing (when the module
finished parsing). This removes the append in parsing the module file.
Closes #13826
|
|
|
|
|
|
Commits for details.
This shouldn't change the generated code at all (except for switching to `LitBinary` from an explicit ExprVec of individual ExprLit bytes for `prefix_bytes`).
|
|
Clearly storing them as `char` is semantically nicer, but this also
fixes a bug whereby `quote_expr!(cx, 'a')` wasn't working, because the
code created by quotation was not matching the actual AST definitions.
|
|
|
|
This is a quick fix for repeated documentation descriptions in certain modules.
Following is a list of the faulty modules I found. I ran `pcregrep -r -M "<p>(.+)\n\1" doc` on the html documentation to help identify them.
- [rustuv::uvio](http://static.rust-lang.org/doc/master/rustuv/uvio/index.html)
- [rustuv::uvll](http://static.rust-lang.org/doc/master/rustuv/uvll/index.html)
- [std::rt::backtrace](http://static.rust-lang.org/doc/master/std/rt/backtrace/index.html)
- [std::rt::env](http://static.rust-lang.org/doc/master/std/rt/env/index.html)
- [std::rt::global_heap](http://static.rust-lang.org/doc/master/std/rt/global_heap/index.html)
- [std::rt::local_heap](http://static.rust-lang.org/doc/master/std/rt/local_heap/index.html)
- [std::rt::rtio](http://static.rust-lang.org/doc/master/std/rt/rtio/index.html)
- [std::rt::task](http://static.rust-lang.org/doc/master/std/rt/task/index.html)
- [std::rt::thread](http://static.rust-lang.org/doc/master/std/rt/thread/index.html)
- [std::rt::unwind](http://static.rust-lang.org/doc/master/std/rt/unwind/index.html)
- [syntax::parse::classify](http://static.rust-lang.org/doc/master/syntax/parse/classify/index.html)
- [syntax::parse::common](http://static.rust-lang.org/doc/master/syntax/parse/common/index.html)
After a little testing, I discovered that moving the documentation inside (`//!`) instead of outside (`///`) modules fixed the immediate problem. I went through the trouble of moving the documentation, and with this commit there are no more repeated descriptions within those faulty modules.
This does not fix the underlying problem though. We should look into why having the documentation outside instead of inside caused the descriptions to be repeated. I will create a separate issue with my findings on the subject if necessary.
In the meantime, this simple fix should be enough.
|
|
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.
|
|
|
|
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 commit cleans them up altogether.
|
