| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Previously, if you wanted to bind a field mutably or by ref, you had to
do something like Foo { x: ref mut x }. You can now just do
Foo { ref mut x }.
Closes #6137
|
|
It's twenty lines longer, but makes for clearer separation of strict and
reserved keywords (probably a good thing) and removes another moving
part (the definitions of `(STRICT|RESERVED)_KEYWORD_(START|FINAL)`).
|
|
- underscore ("_")
- unary ("unary")
- not_fn ("!")
- idx_fn ("[]")
- unary_minus_fn ("unary-")
- item ("item")
- block ("block")
- stmt ("stmt")
- pat ("pat")
- expr ("expr")
- ty ("ty")
- ident ("ident")
- path ("path")
- descrim ("descrim")
- clownshoe_stack_shim ("__rust_stack_shim")
- blk ("blk")
- c_abi ("C")
(And, of course, renumber everything to match.)
|
|
I also renumbered things at the same time; ``in`` was shifted into its
alphabetical position and the reserved keywords were reordered (a couple
of them were out of order).
|
|
Previously, if you wanted to bind a field mutably or by ref, you had to
do something like Foo { x: ref mut x }. You can now just do
Foo { ref mut x }.
Closes #6137
|
|
|
|
|
|
|
|
This reverts commit c54427ddfbbab41a39d14f2b1dc4f080cbc2d41b.
Leave the #[ignores] in that were added to rustpkg tests.
Conflicts:
src/librustc/driver/driver.rs
src/librustc/metadata/creader.rs
|
|
r=alexcrichton
The comments on this function date back from when it was used for `for`
expressions in addition to `do` expressions.
|
|
This function had type &[u8] -> ~str, i.e. it allocates a string
internally, even though the non-allocating version that take &[u8] ->
&str and ~[u8] -> ~str are all that is necessary in most circumstances.
|
|
The comments on this function date back from when it was used for `for`
expressions in addition to `do` expressions.
|
|
|
|
**Note**: I only tested on top of my #10670 PR, size reductions come from both change sets.
With this, [more enums are shrinked](https://gist.github.com/eddyb/08fef0dfc6ff54e890bc), the most significant one being `ast_node`, from 104 bytes (master) to 96 (#10670) and now to 32 bytes.
My own testcase requires **200MB** less when compiling (not including the other **200MB** gained in #10670), and rustc-stage2 is down by about **130MB**.
I believe there is more to gain by fiddling with the enums' layouts.
|
|
|
|
critical enum sizes.
|
|
This PR does some small modernizations to the json library. First is to remove the `@` boxes, second is to rename the constructors to `new`.
|
|
|
|
|
|
|
|
|
|
|
|
Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.
Also update the manual for these changes, and modernify the EBNF for comments.
Closes #10638
|
|
|
|
### Rationale
There is no reason to support more than 2³² nodes or names at this moment, as compiling something that big (even without considering the quadratic space usage of some analysis passes) would take at least **64GB**.
Meanwhile, some can't (or barely can) compile rustc because it requires almost **1.5GB**.
### Potential problems
Can someone confirm this doesn't affect metadata (de)serialization? I can't tell myself, I know nothing about it.
### Results
Some structures have a size reduction of 25% to 50%: [before](https://gist.github.com/luqmana/3a82a51fa9c86d9191fa) - [after](https://gist.github.com/eddyb/5a75f8973d3d8018afd3).
Sadly, there isn't a massive change in the memory used for compiling stage2 librustc (it doesn't go over **1.4GB** as [before](http://huonw.github.io/isrustfastyet/mem/), but I can barely see the difference).
However, my own testcase (previously peaking at **1.6GB** in typeck) shows a reduction of **200**-**400MB**.
|
|
|
|
|
|
language.
|
|
|
|
Fixes #3614.
|
|
Fixes #3614.
|
|
Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.
Closes #10636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix #10283.
|
|
|
|
|
|
|
|
Associated with Issue #6563.
Useful for Apollo Guidance Computer simulation, Unix file system permissions, and maybe one or two other things.
|
|
|
|
This adds bindings to the remaining functions provided by libuv, all of which
are useful operations on files which need to get exposed somehow.
Some highlights:
* Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type
* Moved all file-related methods to be static methods under `File`
* All directory related methods are still top-level functions
* Created `io::FilePermission` types (backed by u32) that are what you'd expect
* Created `io::FileType` and refactored `FileStat` to use FileType and
FilePermission
* Removed the expanding matrix of `FileMode` operations. The mode of reading a
file will not have the O_CREAT flag, but a write mode will always have the
O_CREAT flag.
Closes #10130
Closes #10131
Closes #10121
|
|
This commit moves all thread-blocking I/O functions from the std::os module.
Their replacements can be found in either std::rt::io::file or in a hidden
"old_os" module inside of native::file. I didn't want to outright delete these
functions because they have a lot of special casing learned over time for each
OS/platform, and I imagine that these will someday get integrated into a
blocking implementation of IoFactory. For now, they're moved to a private module
to prevent bitrot and still have tests to ensure that they work.
I've also expanded the extensions to a few more methods defined on Path, most of
which were previously defined in std::os but now have non-thread-blocking
implementations as part of using the current IoFactory.
The api of io::file is in flux, but I plan on changing it in the next commit as
well.
Closes #10057
|
|
|
|
work
|
|
|
