summary refs log tree commit diff
path: root/src/libstd
AgeCommit message (Collapse)AuthorLines
2016-10-05Auto merge of #36944 - brson:modos, r=alexcrichtonbors-3/+3
Fix mod declarations on untested platforms r? @alexcrichton
2016-10-05Fixed small typo in `BufRead` commentsRazican-1/+1
`BufRead` comments, in the `Seek` trait implementation, was talking about allocating 8 *ebibytes*. It was a typo, the correct unit is *exbibytes*, since *ebibytes* don't even exist. The calculation is correct, though.
2016-10-04Haiku: Fix IPv6 target_os checkAlexander von Gluck IV-1/+1
2016-10-04Rollup merge of #36938 - tmiasko:cursor-seek-overflow, r=alexcrichtonManish Goregaokar-7/+18
Check for overflow in Cursor<Vec<u8>>::write. Ensure that cursor position fits into usize, before proceeding with write. Fixes issue #36884.
2016-10-04Rollup merge of #36928 - GuillaumeGomez:error_urls, r=steveklabnikManish Goregaokar-4/+8
Add missing urls for error module r? @steveklabnik
2016-10-04Rollup merge of #36916 - frewsxcv:patch-1, r=alexcrichtonManish Goregaokar-1/+1
Update unstable attr to reference tracking issue.
2016-10-04Rollup merge of #36902 - ollie27:stab_impls, r=alexcrichtonManish Goregaokar-18/+15
std: Correct stability attributes for some implementations These are displayed by rustdoc so should be correct.
2016-10-03Add two functions to check type of SockAddrAbhishek Chanda-0/+35
These can be used to determine the type of the underlying IP address
2016-10-03Add two functions to check type of given addressAbhishek Chanda-0/+32
The is_v4 function returns true if the given IP is v4. The is_v6 function returns true if the IP is v6.
2016-10-03Fix mod declarations on untested platformsBrian Anderson-3/+3
2016-10-03Check for overflow in Cursor<Vec<u8>>::write.Tomasz Miąsko-7/+18
Ensure that cursor position fits into usize, before proceeding with write. Fixes issue #36884.
2016-10-03Auto merge of #36815 - alexcrichton:stabilize-1.13, r=aturonbors-12/+37
std: Stabilize and deprecate APIs for 1.13 This commit is intended to be backported to the 1.13 branch, and works with the following APIs: Stabilized * `i32::checked_abs` * `i32::wrapping_abs` * `i32::overflowing_abs` * `RefCell::try_borrow` * `RefCell::try_borrow_mut` Deprecated * `BinaryHeap::push_pop` * `BinaryHeap::replace` * `SipHash13` * `SipHash24` * `SipHasher` - use `DefaultHasher` instead in the `std::collections::hash_map` module Closes #28147 Closes #34767 Closes #35057 Closes #35070
2016-10-03std: Stabilize and deprecate APIs for 1.13Alex Crichton-12/+37
This commit is intended to be backported to the 1.13 branch, and works with the following APIs: Stabilized * `i32::checked_abs` * `i32::wrapping_abs` * `i32::overflowing_abs` * `RefCell::try_borrow` * `RefCell::try_borrow_mut` * `DefaultHasher` * `DefaultHasher::new` * `DefaultHasher::default` Deprecated * `BinaryHeap::push_pop` * `BinaryHeap::replace` * `SipHash13` * `SipHash24` * `SipHasher` - use `DefaultHasher` instead in the `std::collections::hash_map` module Closes #28147 Closes #34767 Closes #35057 Closes #35070
2016-10-03Add missing urls for error moduleGuillaume Gomez-4/+8
2016-10-03Auto merge of #36766 - nnethercote:hash-span-capacity, r=blussbors-90/+122
Clarify HashMap's capacity handling. HashMap has two notions of "capacity": - "Usable capacity": the number of elements a hash map can hold without resizing. This is the meaning of "capacity" used in HashMap's API, e.g. the `with_capacity()` function. - "Internal capacity": the number of allocated slots. Except for the zero case, it is always larger than the usable capacity (because some slots must be left empty) and is always a power of two. HashMap's code is confusing because it does a poor job of distinguishing these two meanings. I propose using two different terms for these two concepts. Because "capacity" is already used in HashMap's API to mean "usable capacity", I will use a different word for "internal capacity". I propose "span", though I'm happy to consider other names.
2016-10-03Avoid overflow check in `HashMap::reserve`'s fast path.Nicholas Nethercote-2/+3
2016-10-02Update unstable attr to reference tracking issue.Corey Farwell-1/+1
2016-10-02Auto merge of #36807 - brson:pal, r=brsonbors-880/+959
Restrict where in the tree platform-specific cfgs may be mentioned With the ports of Rust never ending, it's important that we keep things tidy. The main thing this PR does is introduce a new "pal" (platform abstraction layer) tidy check that limits where platform-specific CFGs may appear. This is intended to maintain existing standards of code organization in hopes that the standard library will continue to be refactored to isolate platform-specific bits, making porting easier; where "standard library" roughly means "all the dependencies of the std and test crates". This generally means placing restrictions on where `cfg(unix)`, `cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear, the basic objective being to isolate platform-specific code to the platform-specific `std::sys` modules, and to the allocation, unwinding, and libc crates. Following are the basic rules, though there are currently exceptions: - core may not have platform-specific code - liballoc_system may have platform-specific code - liballoc_jemalloc may have platform-specific code - libpanic_abort may have platform-specific code - libpanic_unwind may have platform-specific code - other crates in the std facade may not - std may have platform-specific code in the following places - sys/unix/ - sys/windows/ - os/ There are plenty of exceptions today though, noted in the whitelist. The end-state, IMO, is for the standard library to be portable by porting only `std::sys` (possibly extracted to its own crate), an allocator crate, an unwinder crate, and possibly a libc crate (if std depends on it); but that outcome is far off and independent of the utility of enforcing where such code lives today. cc @rust-lang/libs
2016-10-02Move platform-specific arg handling to sys::argsBrian Anderson-281/+294
2016-10-02Add a platform-abstraction tidy scriptBrian Anderson-3/+6
This is intended to maintain existing standards of code organization in hopes that the standard library will continue to be refactored to isolate platform-specific bits, making porting easier; where "standard library" roughly means "all the dependencies of the std and test crates". This generally means placing restrictions on where `cfg(unix)`, `cfg(windows)`, `cfg(target_os)` and `cfg(target_env)` may appear, the basic objective being to isolate platform-specific code to the platform-specific `std::sys` modules, and to the allocation, unwinding, and libc crates. Following are the basic rules, though there are currently exceptions: - core may not have platform-specific code - liballoc_system may have platform-specific code - liballoc_jemalloc may have platform-specific code - libpanic_abort may have platform-specific code - libpanic_unwind may have platform-specific code - other crates in the std facade may not - std may have platform-specific code in the following places - sys/unix/ - sys/windows/ - os/ There are plenty of exceptions today though, noted in the whitelist.
2016-10-02Auto merge of #36404 - christopherdumas:master, r=GuillaumeGomezbors-3/+10
Documentation change to macros.rs for `includes!` I'm not sure if this documentation is clear or extensive enough, but this is just to get started on the problem, fixes issue #36387.
2016-10-01std: Correct stability attributes for some implementationsOliver Middleton-18/+15
These are displayed by rustdoc so should be correct.
2016-10-01std: Remove plattform-specific code from os_strBrian Anderson-11/+0
2016-10-01std: Move platform specific stdio code into sysBrian Anderson-5/+6
2016-10-01std: Move platform specific memchr code into sysBrian Anderson-271/+309
2016-10-01std: Move platform specific env code into sysBrian Anderson-183/+203
2016-10-01std: Move platform specific path code into sysBrian Anderson-126/+141
2016-10-01Auto merge of #36824 - kali:master, r=alexcrichtonbors-5/+27
SO_NOSIGPIPE and MSG_NOSIGNAL (rebased #36426) I'm not sure what happened when I pushed a rebased branch on #36426 , github closed it...
2016-09-30Auto merge of #36339 - brson:emscripten-new, r=alexcrichtonbors-30/+76
Working asmjs and wasm targets This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman. It does a few things: - Updates LLVM with the emscripten [fastcomp](https://github.com/rust-lang/llvm/pull/50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets. - Teaches rustbuild to correctly link C code with emscripten - Updates gcc-rs to work correctly with emscripten - Teaches rustbuild to run crate tests for emscripten with node - Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode - Modifies libtest to run in single-threaded mode for emscripten - Ignores a host of tests that don't work yet, mostly dealing with threads and I/O - Updates libc with wasm32 definitions (presently the same as asmjs) - Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm Notes and caveats: - This is only known to work with `--enable-rustbuild`. - The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node https://github.com/kripken/emscripten/issues/4542, but hello.rs does seem to work when run on node via the binaryen interpreter - This requires an up to date installation of the emscripten sdk from its incoming branch - Unwinding is very broken - When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies. https://github.com/rust-lang/rust/issues/36317 tracks work on this. Fixes https://github.com/rust-lang/rust/issues/36515 Fixes https://github.com/rust-lang/rust/issues/36515 Fixes https://github.com/rust-lang/rust/issues/36356
2016-09-30Call emcc with ERROR_ON_UNDEFINED_SYMBOLSBrian Anderson-5/+18
2016-09-30Ignore various entire test modules on emscriptenBrian Anderson-125/+11
2016-09-30Change the sigs of set_print/set_panic to allow restoring the default objectsBrian Anderson-4/+4
2016-09-30Ignore entire test modules on emscripten instead of individual testsBrian Anderson-132/+10
2016-09-30Ignore lots and lots of std tests on emscriptenBrian Anderson-0/+252
2016-09-30Preliminary wasm32 supportBrian Anderson-2/+19
2016-09-30Rollup merge of #36851 - tmiasko:fix-read-until-docs, r=blussSteve Klabnik-7/+3
Fix BufRead::read_until documentation. Second paragraph already fully explains what happens when EOF is encountered. The third paragraph (removed one) is spurious and misleading.
2016-09-30Rollup merge of #36841 - GuillaumeGomez:process_doc, r=steveklabnikSteve Klabnik-1/+19
Improve process module doc a bit r? @steveklabnik
2016-09-30Rollup merge of #36833 - tmiasko:system-time-error, r=steveklabnikSteve Klabnik-1/+1
Reword description of SystemTimeError. Repalce timestamp with a system time, to be more consistent with remaining documentation. r? @steveklabnik
2016-09-30Rollup merge of #36535 - GuillaumeGomez:macro_url, r=steveklabnikSteve Klabnik-1/+1
Update to new macro url syntax r? @steveklabnik
2016-09-30Fix BufRead::{read_until, read_line} documentation.Tomasz Miąsko-7/+3
2016-09-29Auto merge of #36557 - sfackler:fix-hashdos-docs, r=alexcrichtonbors-8/+22
Clean up hasher discussion on HashMap * We never want to make guarantees about protecting against attacks. * "True randomness" is not the right terminology to be using in this context. * There is significantly more nuance to the performance of SipHash than "somewhat slow". r? @steveklabnik Follow up to discussion on #35371
2016-09-30add println!() macro with out any arguments石博文-0/+2
2016-09-30Improve process module doc a bitGuillaume Gomez-1/+19
2016-09-29Mention FNVSteven Fackler-1/+1
2016-09-29Auto merge of #36377 - tormol:encode_utf, r=alexcrichtonbors-9/+12
Change encode_utf{8,16}() to write to a buffer and panic if it's too small cc #27784 Should the "A buffer that's too small" examples be removed and replaced by tests?
2016-09-29Reword description of SystemTimeError.Tomasz Miąsko-1/+1
Repalce timestamp with a system time, to be more consistent with remaining documentation.
2016-09-29Clarify HashMap's capacity handling.Nicholas Nethercote-90/+121
This commit does the following. - Changes the terminology for capacities used within HashMap's code. "Internal capacity" is now consistently "raw capacity", and "usable capacity" is now consistently just "capacity". This makes the code easier to understand. - Reworks capacity and raw capacity computations. Raw capacity computations are now handled in a single place: `DefaultResizePolicy::raw_capacity()`. This function correctly returns zero when given zero, which means that the following cases now result in a capacity of zero when they previously did not. * `Hash{Map,Set}::with_capacity(0)` * `Hash{Map,Set}::with_capacity_and_hasher(0)` * `Hash{Map,Set}::shrink_to_fit()`, when used with a hash map/set whose elements have all been removed - Strengthens the language used in the comments describing the above functions, to make it clearer when they will result in a map/set with a capacity of zero. The new language is based on the language used for the corresponding functions in `Vec`. - Adds tests for the above zero-capacity cases. - Removes `test_resize_policy` because it is no longer useful.
2016-09-28Rollup merge of #36811 - brson:bootstrap, r=alexcrichtonJonathan Turner-2/+0
Update bootstrap compiler
2016-09-28Rollup merge of #36741 - matklad:no-flacky-test, r=alexcrichtonJonathan Turner-1/+3
Remove CString drop test. The test relies on the undefined behavior, and so may fail in some circumstances. This can be worked around by stubbing a memory allocator in the test, but it is a bit of work, and LLVM could still theoretically eliminate the write of the zero byte in release mode (which is intended). So let's just remove the test and mark the function as inline. It shouldn't be optimized away when inlined into the debug build of user's code. Supersedes #36607 r? @alexcrichton
2016-09-28Remove stage0 hacksBrian Anderson-2/+0
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-28 16:48:14 +0000