| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #6830.
|
|
|
|
r=alexcrichton
This should block on #14323
|
|
[breaking-change]
|
|
|
|
or `for`s.
|
|
Fixes #13678.
|
|
[breaking-change]
|
|
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.
|
|
[breaking-change]
|
|
|
|
|
|
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 uses the trick of replacing the << token with a < token to parse closure
types correctly.
Closes #13324
|
|
* 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
|
|
|
|
|
|
|
|
|
|
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]
|
|
r? @alexcrichton
|
|
This is needed to bootstrap fix for #5723.
|
|
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
|
|
|
|
|
|
|
|
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.
|
|
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Closes #9390
Closes #13684
Closes #13709
|
|
RFC: 0008-match-arm-attributes
|
|
Specifically, the method parameter cardinality mismatch or missing
method error message span now gets method itself exactly. It was the
whole expression.
Closes #9390
Closes #13684
Closes #13709
|
|
|
|
|
|
When reporting "consider removing this semicolon" hint message, the
offending semicolon may come from macro call site instead of macro
itself. Using the more appropriate span makes the hint more helpful.
Closes #13428.
|
|
No subtyping, no interaction with traits. Partially addresses #9912.
|
|
|
|
When reporting "consider removing this semicolon" hint message, the
offending semicolon may come from macro call site instead of macro
itself. Using the more appropriate span makes the hint more helpful.
Closes #13428.
|
|
Closes #11227.
|
|
This removes the `priv` keyword from the language and removes private enum
variants as a result. The remaining use cases of private enum variants were all
updated to be a struct with one private field that is a private enum.
RFC: 0006-remove-priv
Closes #13535
|
|
|
|
libstd: Implement `StrBuf`, a new string buffer type like `Vec`, and port all code over to use it.
Rebased & tests-fixed version of https://github.com/mozilla/rust/pull/13269
|
