about summary refs log tree commit diff
path: root/src/libstd/lib.rs
AgeCommit message (Collapse)AuthorLines
2020-04-26Add Read/Write::can_read/write_vectoredSteven Fackler-0/+1
When working with an arbitrary reader or writer, code that uses vectored operations may end up being slower than code that copies into a single buffer when the underlying reader or writer doesn't actually support vectored operations. These new methods allow you to ask the reader or witer up front if vectored operations are efficiently supported. Currently, you have to use some heuristics to guess by e.g. checking if the read or write only accessed the first buffer. Hyper is one concrete example of a library that has to do this dynamically: https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
2020-04-25Bump bootstrap compilerMark Rousskov-4/+3
2020-04-20Auto merge of #71007 - Amanieu:deprecate_asm, r=Mark-Simulacrumbors-0/+1
Deprecate the asm! macro in favor of llvm_asm! Since we will be changing the syntax of `asm!` soon, deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed. RFC: https://github.com/rust-lang/rfcs/pull/2843
2020-04-16Dogfood or_patterns in the standard libraryJosh Stone-0/+1
2020-04-15Deprecate the asm! macroAmanieu d'Antras-0/+1
2020-04-05Remove labels in libstd/lib.rs macro importsYoshua Wuyts-14/+2
These labels were probably moved around when rustfmt was introduced.
2020-03-28Replace last mention of IRC with DiscordBenjamin Kästner-1/+3
Mozilla's IRC service was shut down in March 2020. The official instant messaging variant has been Discord for a while, and most of the links were already replaced by #61524. This was the last line that came up with `irc.mozilla.org` or any combination of "irc.*#[a-z]+" in a `git grep`: git grep -i -E "irc.*#[a-z]+" As there is only one other link directly to Rust's discord, I used the same Markdown link `[rust-discord]` as in `bootstrap/README.md` to stay consistent. This might come in handy if the chat platform changes at a later point again. As an aside: for those interested in the use of IRC, Mozilla's [wiki] still offers a lot of in-depth knowledge. [wiki]: https://wiki.mozilla.org/IRC
2020-03-26Rename asm! to llvm_asm!Amanieu d'Antras-23/+4
asm! is left as a wrapper around llvm_asm! to maintain compatibility.
2020-03-26introduce `negative_impls` feature gate and documentNiko Matsakis-0/+1
They used to be covered by `optin_builtin_traits` but negative impls are now applicable to all traits, not just auto traits. This also adds docs in the unstable book for the current state of auto traits.
2020-03-23Update src/libstd/lib.rsSaoirse Shipwreckt-1/+1
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
2020-03-23Add `wake_trait` feature directive to stdWithout Boats-0/+1
2020-03-23Add Wake trait for safe construction of Wakers.Without Boats-0/+5
Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`: - We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`. Therefore, the Wake trait was left out of the initial version of the task waker API. However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait, which contains two methods - A required method `wake`, which is called by `Waker::wake` - A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From<Arc<W>> for RawWaker`.
2020-03-17Rollup merge of #69870 - petrochenkov:cfgacc, r=matthewjasperMazdak Farrokhzad-0/+1
expand: Implement something similar to `#[cfg(accessible(path))]` cc https://github.com/rust-lang/rust/issues/64797 The feature is implemented as a `#[cfg_accessible(path)]` attribute macro rather than as `#[cfg(accessible(path))]` because it needs to wait until `path` becomes resolvable, and `cfg` cannot wait, but macros can wait. Later we can think about desugaring or not desugaring `#[cfg(accessible(path))]` into `#[cfg_accessible(path)]`. This implementation is also incomplete in the sense that it never returns "false" from `cfg_accessible(path)`, it requires some tweaks to resolve, which is not quite ready to answer queries like this during early resolution. However, the most important part of this PR is not `cfg_accessible` itself, but expansion infrastructure for retrying expansions. Before this PR we could say "we cannot resolve this macro path, let's try it later", with this PR we can say "we cannot expand this macro, let's try it later" as well. This is a pre-requisite for - turning `#[derive(...)]` into a regular attribute macro, - properly supporting eager expansion for macros that cannot yet be resolved like ``` fn main() { println!(not_available_yet!()); } macro_rules! make_available { () => { #[macro_export] macro_rules! not_available_yet { () => { "Hello world!" } }} } make_available!(); ```
2020-03-15Use min_specialization in libstd and libproc_macroMatthew Jasper-1/+2
2020-03-10Rollup merge of #69514 - GuillaumeGomez:remove-spotlight, r=kinnisonMazdak Farrokhzad-1/+0
Remove spotlight I had a few comments saying that this feature was at best misunderstood or not even used so I decided to organize a poll about on [twitter](https://twitter.com/imperioworld_/status/1232769353503956994). After 87 votes, the result is very clear: it's not useful. Considering the amount of code we have just to run it, I think it's definitely worth it to remove it. r? @kinnison cc @ollie27
2020-03-10builtin_macros: Add attribute macro `#[cfg_accessible(path)]`Vadim Petrochenkov-0/+1
2020-03-04Auto merge of #68952 - faern:stabilize-assoc-int-consts, r=dtolnaybors-1/+0
Stabilize assoc_int_consts associated int/float constants The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325. * Stabilize all constants under the `assoc_int_consts` feature flag. * Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred. * Update documentation examples to use new constants. * Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway. r? @LukasKalbertodt
2020-02-27Remove spotlight usageGuillaume Gomez-1/+0
2020-02-26Rollup merge of #67637 - Mark-Simulacrum:primitive-mod, r=dtolnayDylan DPC-1/+4
Add primitive module to libcore This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from. Fixes #44865
2020-02-23Bump core::primitive to 1.43David Tolnay-1/+1
2020-02-15Rollup merge of #64069 - ↵Dylan DPC-0/+1
danielhenrymantilla:feature/cstring_from_vec_of_nonzerou8, r=KodrAus Added From<Vec<NonZeroU8>> for CString Added a `From<Vec<NonZeroU8>>` `impl` for `CString` # Rationale - `CString::from_vec_unchecked` is a subtle function, that makes `unsafe` code harder to audit when the generated `Vec`'s creation is non-trivial. This `impl` allows to write safer `unsafe` code thanks to the very explicit semantics of the `Vec<NonZeroU8>` type. - One such situation is when trying to `.read()` a `CString`, see issue #59229. - this lead to a PR: #59314, that was closed for being too specific / narrow (it only targetted being able to `.read()` a `CString`, when this pattern could have been generalized). - the issue suggested another route, based on `From<Vec<NonZeroU8>>`, which is indeed a less general and more concise code pattern. - quoting @shnatsel: - > For me the main thing about making this safe is simplifying auditing - people have spent like an hour looking at just this one unsafe block in libflate because it's not clear what exactly is unchecked, so you have to look it up when auditing anyway. This has distracted us from much more serious memory safety issues the library had. Having this trivial impl in stdlib would turn this into safe code with compiler more or less guaranteeing that it's fine, and save anyone auditing the code a whole lot of time.
2020-02-12Stabilize assoc_int_constsLinus Färnstrand-1/+0
2020-02-06Add primitive module to libcore/stdMark Rousskov-1/+4
This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from.
2020-02-05Auto merge of #68755 - Tyg13:update_stdarch, r=alexcrichtonbors-6/+0
Update `rust-lang/stdarch` submodule Update submodule [rust-lang/stdarch](https://github.com/rust-lang/stdarch/)
2020-02-04Added From<Vec<NonZeroU8>> for CStringDaniel Henry-Mantilla-0/+1
Updated tracking issue number Added safeguards for transmute_vec potentially being factored out elsewhere Clarified comment about avoiding mem::forget Removed unneeded unstable guard Added back a stability annotation for CI Minor documentation improvements Thanks to @Centril's code review Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Improved layout checks, type annotations and removed unaccurate comment Removed unnecessary check on array layout Adapt the stability annotation to the new 1.41 milestone Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com> Simplify the implementation. Use `Vec::into_raw_parts` instead of a manual implementation of `Vec::transmute`. If `Vec::into_raw_parts` uses `NonNull` instead, then the code here will need to be adjusted to take it into account (issue #65816) Reduce the whitespace of safety comments
2020-02-04Auto merge of #68708 - Mark-Simulacrum:stage0-step, r=pietroalbinibors-1/+0
Step stage0 to bootstrap from 1.42 This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
2020-02-03Rollup merge of #68797 - GuillaumeGomez:link-to-types, r=Dylan-DPCDylan DPC-2/+2
Fix links to types instead of modules r? @Dylan-DPC
2020-02-03Fix links to types instead of modulesGuillaume Gomez-2/+2
2020-02-01stdarch: update submodule.Tyler Lanphear-6/+0
2020-01-31Drop cfg(bootstrap) codeMark Rousskov-1/+0
2020-01-23Unlock assoc_int_consts in core+stdLinus Färnstrand-0/+1
2020-01-20Auto merge of #68066 - CAD97:stabilize-manuallydrop-take, ↵bors-1/+0
r=Amanieu,Mark-Simulacrum Stabilize ManuallyDrop::take Tracking issue: closes #55422 FCP merge: https://github.com/rust-lang/rust/issues/55422#issuecomment-572653619 Reclaims the doc improvements from closed #62198. ----- Stable version is a simple change if necessary. Proposal: [relnotes] (this changes how to best take advantage of `ManuallyDrop`, esp. wrt. `Drop::drop` and finalize-by-value members)
2020-01-18slice_patterns: remove internal uses of gateMazdak Farrokhzad-1/+1
2020-01-09stabalize ManuallyDrop::takeCAD97-1/+0
2020-01-04Rollup merge of #67137 - anp:tracked-panic-internals, r=eddybDylan DPC-0/+1
libstd uses `core::panic::Location` where possible. cc @eddyb
2020-01-04core and std macros and panic internals use panic::Location::caller.Adam Perry-0/+1
2019-12-31Revert "core: add IntoFuture trait and support for await"Wesley Wiser-1/+0
This reverts commit f35517ee861dc012ccc26083dd4520045e2c4f6f.
2019-12-28Rollup merge of #67659 - SimonSapin:matches, r=rkruppeOliver Scherer-1/+0
Stabilize the `matches!` macro Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119
2019-12-27core: add IntoFuture trait and support for awaitSean McArthur-0/+1
2019-12-27Stabilize the `matches!` macroSimon Sapin-1/+0
Fixes https://github.com/rust-lang/rust/issues/65721 FCP: https://github.com/rust-lang/rust/issues/65721#issuecomment-569118119
2019-12-22Format the worldMark Rousskov-73/+73
2019-12-19Correct the todo! stabilization versionJakub Kądziołka-1/+1
2019-12-18Propagate cfg bootstrapMark Rousskov-2/+0
2019-12-14Auto merge of #67224 - nikomatsakis:revert-stabilization-of-never-type, ↵bors-1/+1
r=centril Revert stabilization of never type Fixes https://github.com/rust-lang/rust/issues/66757 I decided to keep the separate `never-type-fallback` feature gate, but tried to otherwise revert https://github.com/rust-lang/rust/pull/65355. Seemed pretty clean. ( cc @Centril, author of #65355, you may want to check this over briefly )
2019-12-14Revert "Stabilize the `never_type`, written `!`."Niko Matsakis-1/+1
This reverts commit 15c30ddd69d6cc3fffe6d304c6dc968a5ed046f1.
2019-12-13Reuse the `staged_api` feature for `rustc_const_unstable`Oliver Scherer-1/+1
2019-11-30Rollup merge of #66705 - pitdicker:atomic_mut_ptr, r=KodrAusMazdak Farrokhzad-0/+1
Atomic as_mut_ptr I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type). It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477 Transmuting the pointer directly: ```rust let atomic = AtomicI32::new(1); let ptr = &atomic as *const AtomicI32 as *mut i32; unsafe { ffi(ptr); } ``` A dance with `UnsafeCell`: ```rust let atomic = AtomicI32::new(1); unsafe { let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get(); ffi(ptr); } ``` Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library? An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race." The standard library could make use this method in a few places in the WASM module. cc @RalfJung as you answered my original question.
2019-11-24Use as_mut_ptr instead of castsPaul Dicker-0/+1
2019-11-21Stabilize the `never_type`, written `!`.Mazdak Farrokhzad-1/+1
2019-11-18Remove compiler_builtins_lib feature from libstdYu Ding-1/+0
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 06:30:15 +0000