The general idea is to remove conditions completely from I/O, so in the meantime
remove the read_error condition to mean the same thing as the io_error condition.
Drop the `2` suffix on all of them, updating all code in the process of doing so. This is a completely automated change, and it's dependent on the snapshots going through.
This should close#9468.
I removed the test stating that nested comments should not be implemented.
I had a little chicken-and-egg problem because a comment of the std contains "/*", and adding support for nested comment creates a backward incompatibility in that case, so I had to use a dirty hack to get stage1 and stage2 to compile. This part should be revert when this commit lands in a snapshot.
This is my first non-typo contribution, so I'm open to any comment.
Fixes#9882
Note that the actual checking code is inside a if false in order to compile libstd properly.
libstd uses asm! in rt. If we put ```#[feature(asm)]``` in libstd, it fails to build at stage0 beacause the
asm feature is not known yet by the snapshot compiler.
We must wait that this PR arrives into the snapshot in order to actually activate the checking code.
Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test
before:
time: 469s
memory: 6GB
assertion failure in LLVM (section too large)
after:
time: 2.50s
memory: 124MB
Closes#2598
Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test
before:
time: 469s
memory: 6GB
assertion failure in LLVM (section too large)
after:
time: 2.50s
memory: 124MB
Closes#2598
Standardize the is_sep() functions to be the same in both posix and
windows, and re-export from path. Update extra::glob to use this.
Remove the usage of either, as it's going away.
Move the WindowsPath-specific methods out of WindowsPath and make them
top-level functions of path::windows instead. This way you cannot
accidentally write code that will fail to compile on non-windows
architectures without typing ::windows anywhere.
Remove GenericPath::from_c_str() and just impl BytesContainer for
CString instead.
Remove .join_path() and .push_path() and just implement BytesContainer
for Path instead.
Remove FilenameDisplay and add a boolean flag to Display instead.
Remove .each_parent(). It only had one caller, so just inline its
definition there.
* Allow named parameters to specify width/precision
* Intepret the format string '0$' as "width is the 0th argument" instead of
thinking the lone '0' was the sign-aware-zero-padding flag. To get both you'd
need to put '00$' which makes more sense if you want both to happen.
Closes#9669
Rewrite these methods as methods on Display and FilenameDisplay. This
turns
do path.with_display_str |s| { ... }
into
do path.display().with_str |s| { ... }
Add a new trait BytesContainer that is implemented for both byte vectors
and strings.
Convert Path::from_vec and ::from_str to one function, Path::new().
Remove all the _str-suffixed mutation methods (push, join, with_*,
set_*) and modify the non-suffixed versions to use BytesContainer.
Remove the old path.
Rename path2 to path.
Update all clients for the new path.
Also make some miscellaneous changes to the Path APIs to help the
adoption process.
There's currently a fair amount of code which is being ignored on unnamed blocks
(which are the default now), and I opted to leave it commented out for now. I
intend on very soon revisiting on how we perform linking with extern crates in
an effort to support static linking.
It's unclear to me why these currently aren't allowed, and my best guess is that
a long time ago we didn't strip the ast of cfg nodes before syntax expansion.
Now that this is done, I'm not certain that we should continue to prohibit this
functionality.
This is a step in the right direction towards #5605, because now we can add an
empty `std::macros` module to the documentation with a bunch of empty macros
explaining how they're supposed to be used.
It's unclear to me why these currently aren't allowed, and my best guess is that
a long time ago we didn't strip the ast of cfg nodes before syntax expansion.
Now that this is done, I'm not certain that we should continue to prohibit this
functionality.
This is a step in the right direction towards #5605, because now we can add an
empty `std::macros` module to the documentation with a bunch of empty macros
explaining how they're supposed to be used.
r? anybody It's more helpful to list the span of each open delimiter seen so far
than to print out an error with the span of the last position in the file.
Closes#2354
For the benefit of the pretty printer we want to keep track of how
string literals in the ast were originally represented in the source
code.
This commit changes parser functions so they don't extract strings from
the token stream without at least also returning what style of string
literal it was. This is stored in the resulting ast node for string
literals, obviously, for the package id in `extern mod = r"package id"`
view items, for the inline asm in `asm!()` invocations.
For `asm!()`'s other arguments or for `extern "Rust" fn()` items, I just
the style of string, because it seemed disproportionally cumbersome to
thread that information through the string processing that happens with
those string literals, given the limited advantage raw string literals
would provide in these positions.
The other syntax extensions don't seem to store passed string literals
in the ast, so they also discard the style of strings they parse.
It's more helpful to list the span of each open delimiter seen so far
than to print out an error with the span of the last position in the file.
Closes#2354
Raw string literals are lexed into regular string literals. This is okay
for them to "work" and be usable/testable, but the pretty-printer does
not know about them yet and will just emit regular string literals.
