| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This section was added but the list wasn't updated.
|
|
r? @alexcrichton
|
|
The documentation doesn't appear to describe the `&foo[..]` syntax.
I tried looking in `primitive-types.html#slices` and `std/primitive.slice.html`.
There's an example of partially slicing an array in trpl and a mention of `&foo[..]` in [the standard library documentation](https://doc.rust-lang.org/std/primitive.slice.html), but neither place, from what I can see, actually describes the behavior of `&foo[..]`.
+r? @steveklabnik
|
|
Fixes #24639
|
|
as accepted in [RFC 526](https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md).
Note that this brand new method is marked as **stable**. I judged this safe enough: it’s simple enough that it’s very unlikely to change. Still, I can mark it unstable instead if you prefer.
r? @alexcrichton
|
|
This just fixes some comments made on https://github.com/rust-lang/rust/pull/24632 . The second I think is better unless @steveklabnik actually meant something else.
|
|
r? @alexcrichton
|
|
https://github.com/rust-lang/rust/pull/24631 is related, as it will delete this from the TOC, but I want to keep it here.
|
|
r? @alexcrichton
|
|
as dependency for #24594
|
|
For now, words() is left in (but deprecated), and Words is a type alias for
struct SplitWhitespace.
Also cleaned up references to str.words() throughout codebase.
Closes #15628
|
|
This removes the usage of `#[feature(into_cow, slice_patterns, box_syntax, box_patterns, quote, unsafe_destructor)]` from being used in libsyntax. My main desire for this is that it brings me one step closer to letting [syntex](https://github.com/erickt/rust-syntex) compile with stable rust. Hopefully this doesn't inconvenience rust development.
|
|
When linking an archive statically to an rlib, the compiler will extract all
contents of the archive and add them all to the rlib being generated. The
current method of extraction is to run `ar x`, dumping all files into a
temporary directory. Object archives, however, are allowed to have multiple
entries with the same file name, so there is no method for them to extract their
contents into a directory in a lossless fashion.
This commit adds iterator support to the `ArchiveRO` structure which hooks into
LLVM's support for reading object archives. This iterator is then used to
inspect each object in turn and extract it to a unique location for later
assembly.
|
|
Implement [RFC #1048][rfc].
On Windows, when you create a symbolic link you must specify whether it
points to a directory or a file, even if it is created dangling, while
on Unix, the same symbolic link could point to a directory, a file, or
nothing at all. Furthermore, on Windows special privilege is necessary
to use a symbolic link, while on Unix, you can generally create a
symbolic link in any directory you have write privileges to.
This means that it is unlikely to be able to use symbolic links purely
portably; anyone who uses them will need to think about the cross
platform implications. This means that using platform-specific APIs
will make it easier to see where code will need to differ between the
platforms, rather than trying to provide some kind of compatibility
wrapper.
Furthermore, `soft_link` has no precedence in any other API, so to avoid
confusion, move back to the more standard `symlink` terminology.
Create a `std::os::unix::symlink` for the Unix version that is
destination type agnostic, as well as `std::os::windows::{symlink_file,
symlink_dir}` for Windows.
Because this is a stable API, leave a compatibility wrapper in
`std::fs::soft_link`, which calls `symlink` on Unix and `symlink_file`
on Windows, preserving the existing behavior of `soft_link`.
[rfc]: https://github.com/rust-lang/rfcs/pull/1048
|
|
Check for duplicate loop labels in function bodies.
See also: http://internals.rust-lang.org/t/psa-rejecting-duplicate-loop-labels/1833
The change, which we are putting in as future-proofing in preparation for future potential additions to the language (namely labeling arbitrary blocks and using those labels in borrow expressions), means that code like this will start emitting warnings:
```rust
fn main() {
{ 'a: loop { break; } }
{ 'a: loop { break; } }
}
```
To make the above code compile without warnings, write this instead:
```rust
fn main() {
{ 'a: loop { break; } }
{ 'b: loop { break; } }
}
```
Since this change is only introducing a new warnings, this change is non-breaking.
Fix #21633
|
|
Fixes #24639
|
|
For now, words() is left in (but deprecated), and Words is a type alias for
struct SplitWhitespace.
Also cleaned up references to s.words() throughout codebase.
Closes #15628
|
|
Words struct was stabilied by mistake. Unstabilize.
|
|
When linking an archive statically to an rlib, the compiler will extract all
contents of the archive and add them all to the rlib being generated. The
current method of extraction is to run `ar x`, dumping all files into a
temporary directory. Object archives, however, are allowed to have multiple
entries with the same file name, so there is no method for them to extract their
contents into a directory in a lossless fashion.
This commit adds iterator support to the `ArchiveRO` structure which hooks into
LLVM's support for reading object archives. This iterator is then used to
inspect each object in turn and extract it to a unique location for later
assembly.
|
|
This section was added but the list wasn't updated.
|
|
|
|
|
|
|
|
Replace Path::exists with stable metadata call.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On Windows, when you create a symbolic link you must specify whether it
points to a directory or a file, even if it is created dangling, while
on Unix, the same symbolic link could point to a directory, a file, or
nothing at all. Furthermore, on Windows special privilege is necessary
to use a symbolic link, while on Unix, you can generally create a
symbolic link in any directory you have write privileges to.
This means that it is unlikely to be able to use symbolic links purely
portably; anyone who uses them will need to think about the cross
platform implications. This means that using platform-specific APIs
will make it easier to see where code will need to differ between the
platforms, rather than trying to provide some kind of compatibility
wrapper.
Furthermore, `soft_link` has no precedence in any other API, so to avoid
confusion, move back to the more standard `symlink` terminology.
Create a `std::os::unix::symlink` for the Unix version that is
destination type agnostic, as well as `std::os::windows::{symlink_file,
symlink_dir}` for Windows.
Because this is a stable API, leave a compatibility wrapper in
`std::fs::soft_link`, which calls `symlink` on Unix and `symlink_file`
on Windows, preserving the existing behavior of `soft_link`.
|
|
|
|
|
|
Note: this Warns rather than error on shadowing problems involving labels.
We took this more conservative option mostly due to issues with
hygiene being broken for labels and/or lifetimes.
Add FIXME regarding non-hygienic comparison.
|
|
|
|
|
|
This was moved to https://github.com/rust-lang/term/issues/12
|
|
Looks like these were missed in bf4e77d.
|
|
|
|
Fixes #15679
Fixes #15878
Fixes #15882
Closes #15883
|
|
|
|
as accepted in [RFC 526](https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md).
|
|
|
|
This patch adds a `Debug` impl for `std::fs::File`.
On all platforms (Unix and Windows) it shows the file descriptor.
On Linux, it displays the path and access mode as well.
Ideally we should show the path/mode for all platforms, not just Linux,
but this will do for now.
cc #24570
|
