| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Beef up the docs on the type, as well as adding examples for all
methods.
|
|
Beef up the struct docs, add examples for the methods.
|
|
|
|
update test/compile-fail/feature-gate-box-expr.rs to reflect new feature gates.
Part of what lands with Issue 22181.
|
|
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:
* LLVM changes its IR syntax from time to time, so it's very difficult to
have these files build across many LLVM versions simultaneously. We'll likely
want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
itself, so it makes sense to fold it into a location which can do more
platform-specific checks for various implementation details (such as MSVC 32
vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
end up becoming very useful if we move towards building the standard library
with Cargo.
In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
|
|
Mostly through adding examples.
|
|
Enables bootstrapping a 32-bit MSVC host compiler!
Closes #26602
|
|
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:
* LLVM changes its IR syntax from time to time, so it's very difficult to
have these files build across many LLVM versions simultaneously. We'll likely
want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
itself, so it makes sense to fold it into a location which can do more
platform-specific checks for various implementation details (such as MSVC 32
vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
end up becoming very useful if we move towards building the standard library
with Cargo.
In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
|
|
This can fail on linux for various reasons, such as the /proc filesystem not
being mounted. There are already many cases where we can't set up stack guards,
so just don't worry about this case and communicate that no guard was enabled.
I've confirmed that this allows the compiler to run in a chroot without /proc
mounted.
Closes #22642
|
|
Fixes #26475
I'm not sure this is enough, really, but I'm not totally clear on what specific information would be valuable here. In the original issue, the Java page was pretty decent, but now I can't think of a different way to word it, and copying their prose is of course not acceptable.
thoughts @alexcrichton @aturon @aidanhs ?
|
|
Mostly adding examples.
|
|
Fixes #26475
|
|
This can fail on linux for various reasons, such as the /proc filesystem not
being mounted. There are already many cases where we can't set up stack guards,
so just don't worry about this case and communicate that no guard was enabled.
I've confirmed that this allows the compiler to run in a chroot without /proc
mounted.
Closes #22642
|
|
This is the landing page for all of io, so we should have more than just
a sentence here.
r? @alexcrichton and I know @brson has been caring a lot about landing page style docs lately.
|
|
This makes the primitive descriptions on the front page read properly
as descriptions of types and not of the associated modules.
Having the primitive and module docs derived from the same source
causes problems, primarily that they can't contain hyperlinks
cross-referencing each other.
This crates dedicated private modules in `std` to document the
primitive types, then for all primitives that have a corresponding
module, puts hyperlinks in moth the primitive docs and the module docs
cross-linking each other.
This should help clear up confusion when readers find themselves on
the wrong page.
This also removes all the duplicate `#[doc(primitive)]` tags in various places (especially core), so the core docs will no longer attempt to document the primitives for now. Seems like an acceptable tradeoff to get some cleanup for std.
|
|
cc #24570
r? @alexcrichton
|
|
|
|
This commit fixes building the standard library with the `i686-pc-windows-msvc`
target by correcting an included symbol name to the linker.
|
|
This is the landing page for all of io, so we should have more than just
a sentence here.
|
|
Better and more consistent links to their creators.
|
|
Having the primitive and module docs derived from the same source
causes problems, primarily that they can't contain hyperlinks
cross-referencing each other.
This crates dedicated private modules in `std` to document the
primitive types, then for all primitives that have a corresponding
module, puts hyperlinks in moth the primitive docs and the module docs
cross-linking each other.
This should help clear up confusion when readers find themselves on
the wrong page.
|
|
This makes the primitive descriptions on the front page read properly
as descriptions of types and not of the associated modules.
|
|
These provide various special readers, so point their docs to their
constructor functions in a manner consistent with everything else.
|
|
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.md
Closes #27062
|
|
Adds a path field if a path could be obtained
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
Make them all consistent and link up the documentation.
|
|
This commit fixes the negate_unsigned feature gate to appropriately
account for inferred variables.
This is technically a [breaking-change], but I’d consider it a bug fix.
cc @brson for your relnotes.
Fixes https://github.com/rust-lang/rust/issues/24676
Fixes #26840
Fixes https://github.com/rust-lang/rust/issues/25206
|
|
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.md
Closes #27062
|
|
Add Ipv4Addr tests to verify doc address checking.
|
|
Fixes #26939.
|
|
|
|
I fixed a single character typo.
r? @steveklabnik
|
|
Pretty sure this should apply to the module.
r? @alexcrichton
|
|
|
|
into rollup_central
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In general, it's undesirable to have read_to_end use a buffer with uninitialized memory, as that could lead to undefined behaviour in the event of a bad Read implementation. Since we control the implementations of Read for Stdin and File, however, it should be okay for us to specialise them to improve performance. This PR is to do that!
Adds some unsafe code to deal with creating the buffers. Since the read_to_end function needed to be used from the io and fs crates, I moved it into a newly-created sys::common::io module. Alternatively we could expose the new read_to_end functions to allow people to create their own read_to_end implementations for code they trust.
Benchmarks:
Read a 2.5MB file:
sys_common::io::tests::bench_init_file ... bench: 27,473,317 ns/iter (+/- 2,490,767)
sys_common::io::tests::bench_uninit_file ... bench: 25,611,793 ns/iter (+/- 2,137,387)
Read a buffer full of constant values
sys_common::io::tests::bench_uninitialized ... bench: 12,877,645 ns/iter (+/- 931,025)
sys_common::io::tests::bench_zeroed ... bench: 18,581,082 ns/iter (+/- 1,541,108)
So, approx a 7% speedup for file reading, which I think is worthwhile.
|
|
Yet another attempt to make the prose on the std crate page
clearer and more informative.
This does a lot of things: tightens up the opening, adds useful links
(including a link to the search bar), offers guidance on how to use
the docs, and expands the prelude docs as a useful newbie entrypoint.
r? @steveklabnik cc @aturon
|
|
allowing them to read into a buffer containing uninitialized data,
rather than pay the cost of zeroing.
|
|
|
|
This commit fixes the negate_unsigned feature gate to appropriately
account for infered variables.
This is technically a [breaking-change].
|
|
|
|
Use Vec::drain in BufWriter
I happened past a comment that asked for functionality that we now have.
|
|
I happened past a comment that asked for functionality that we now have.
|
|
|
