about summary refs log tree commit diff
path: root/src/libcore
AgeCommit message (Collapse)AuthorLines
2019-11-13clarify why we can do the ptr castRalf Jung-3/+5
2019-11-13Trailing full stopRalf Jung-1/+1
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-11-13Auto merge of #66156 - Mark-Simulacrum:stage0-step, r=pietroalbinibors-160/+32
Stage0 step r? @pietroalbini
2019-11-12Snap cfgsMark Rousskov-160/+32
2019-11-12Auto merge of #60026 - Aaron1011:feature/miri-unwind, r=RalfJung,oli-obkbors-0/+5
Add hooks for Miri panic unwinding This commits adds in some additional hooks to allow Miri to properly handle panic unwinding. None of this should have any impact on CTFE mode This supports https://github.com/rust-lang/miri/pull/693
2019-11-12update version metadataPeter-35/+35
2019-11-12Rollup merge of #66230 - Axelderan:remove-vestigial-comments, r=alexcrichtonYuki Okushi-2/+0
remove vestigial comments referring to defunct numeric trait hierarchy I've been poking around the numeric trait hierarchy and also some of the actual numeric type implementations. This is a small change but a matter of effective communication. I looked for other related references and saw none.
2019-11-12add Result::map_orLzu Tao-0/+22
2019-11-12stabilize Result::map_or_elseLzu Tao-2/+1
2019-11-12make Result::map_or_else consistent with Option::map_or_elseLzu Tao-2/+5
2019-11-11Use proper intrinsic typeAaron Hill-6/+1
2019-11-11More work on miri_start_panicAaron Hill-1/+6
2019-11-11Fix up intrinsic implementationAaron Hill-1/+1
2019-11-11Add explicit Miri support to libpanic_unwindAaron Hill-0/+5
2019-11-11add NonZeroU16 -> NonZeroUsize and NonZeroI16 -> NonZeroIsizePeter-0/+2
2019-11-10remove irrelevant Safety sectionPeter-38/+34
2019-11-10From<NonZero*> impls for wider NonZero typesPeter-0/+70
issue: https://github.com/rust-lang/rust/issues/66196
2019-11-10Rollup merge of #66217 - RalfJung:diagnostic-items, r=CentrilYuki Okushi-0/+4
invalid_value lint: use diagnostic items This adjusts the invalid_value lint to use diagnostic items. @Centril @oli-obk For some reason, this fails to recognize `transmute` -- somehow the diagnostic item is not found. Any idea why? r? @Centril Cc https://github.com/rust-lang/rust/issues/66075
2019-11-09Fix typoChristopher Durham-1/+1
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-11-09Fix Layout::pad_to_align type mismatchChristopher Durham-2/+3
2019-11-09Layout::pad_to_align is infallibleChristopher Durham-5/+7
2019-11-09add raw ptr variant of UnsafeCell::getRalf Jung-0/+30
2019-11-09partially port invalid_value lint to diagnostic itemsRalf Jung-0/+4
2019-11-09Auto merge of #66242 - Centril:rollup-h73ztr1, r=Centrilbors-0/+4
Rollup of 6 pull requests Successful merges: - #65949 (Move promotion into its own pass) - #65994 (Point at where clauses where the associated item was restricted) - #66050 (Fix C aggregate-passing ABI on powerpc) - #66134 (Point at formatting descriptor string when it is invalid) - #66172 (Stabilize @file command line arguments) - #66226 (add link to unstable book for asm! macro) Failed merges: r? @ghost
2019-11-09Auto merge of #65879 - ohadravid:stabilize-re-rebalance-coherence, ↵bors-15/+12
r=nikomatsakis Stabilize the `re_rebalance_coherence` feature This PR stabilizes [RFC 2451](https://rust-lang.github.io/rfcs/2451-re-rebalancing-coherence.html), re-rebalance coherence. Changes include removing the attribute from tests which tested both the old and new behavior, moving the feature to `accepted` and removing the old logic. I'll also open a [PR](https://github.com/rust-lang-nursery/reference/pull/703) against the reference, updating it with the content of the RFC. Closes #63599 r? @nikomatsakis
2019-11-08remove vestigial comments referring to defunct numeric trait hierarchyAlexander Nye-2/+0
see also https://github.com/rust-lang/rust/pull/23104/files
2019-11-08add link to unstable book for asm! macroLzu Tao-0/+4
2019-11-08Rollup merge of #65580 - SimonSapin:maybeuninit-array, r=AmanieuYuki Okushi-0/+63
Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut` Eventually these will hopefully become the idiomatic way to work with partially-initialized stack buffers. All methods are unstable. Note that `uninit_array` takes a type-level `const usize` parameter, so it is blocked (at least in its current form) on const generics. Example: ```rust use std::mem::MaybeUninit; let input = b"Foo"; let f = u8::to_ascii_uppercase; let mut buffer: [MaybeUninit<u8>; 32] = MaybeUninit::uninit_array(); let vec; let output = if let Some(buffer) = buffer.get_mut(..input.len()) { buffer.iter_mut().zip(input).for_each(|(a, b)| { a.write(f(b)); }); unsafe { MaybeUninit::slice_get_ref(buffer) } } else { vec = input.iter().map(f).collect::<Vec<u8>>(); &vec }; assert_eq!(output, b"FOO"); ```
2019-11-07Implement Debug for MaybeUninitPeter Todd-0/+9
Precedent: UnsafeCell implements Debug even though it can't actually display the value.
2019-11-07Rollup merge of #63793 - oli-obk:🧹, r=dtolnayMazdak Farrokhzad-12/+133
Have tidy ensure that we document all `unsafe` blocks in libcore cc @rust-lang/libs I documented a few and added ignore flags on the other files. We can incrementally document the files, but won't regress any files this way.
2019-11-07MaybeUninit::uninit_array docs: better exampleSimon Sapin-14/+20
2019-11-07Apply docs suggestions from reviewSimon Sapin-4/+4
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-11-07Add `MaybeUninit` methods `uninit_array`, `slice_get_ref`, `slice_get_mut`Simon Sapin-0/+57
2019-11-07Rollup merge of #66017 - LukasKalbertodt:array-into-iter-lint, r=matthewjasperMazdak Farrokhzad-0/+1
Add future incompatibility lint for `array.into_iter()` This is for #65819. This lint warns when calling `into_iter` on an array directly. That's because today the method call resolves to `<&[T] as IntoIterator>::into_iter` but that would change when adding `IntoIterator` impls for arrays. This problem is discussed in detail in #65819. We still haven't decided how to proceed exactly, but it seems like adding a lint is a good idea regardless? Also: this is the first time I implement a lint, so there are probably a lot of things I can improve. I used a different strategy than @scottmcm describes [here](https://github.com/rust-lang/rust/pull/65819#issuecomment-548667847) since I already started implementing this before they commented. ### TODO - [x] Decide if we want this lint -> apparently [we want](https://github.com/rust-lang/rust/pull/65819#issuecomment-548964818) - [x] Open a lint-tracking-issue and add the correct issue number in the code -> https://github.com/rust-lang/rust/issues/66145
2019-11-07Rollup merge of #66117 - olegnn:fixed_linked_list_marker, r=RalfJungYuki Okushi-2/+7
Fixed PhantomData markers in Arc and Rc Include owned internal structs in `PhantomData` markers in `Arc` (`PhantomData<T>` => `PhantomData<ArcInner<T>>`) and `Rc` (`PhantomData<T>` => `PhantomData<RcBox<T>>`).
2019-11-07Rollup merge of #66111 - RalfJung:from_raw_parts, r=CentrilYuki Okushi-23/+60
improve from_raw_parts docs Triggered by https://github.com/rust-lang/rfcs/pull/2806. Hopefully this helps clarify that joining slices across allocations is not possible in Rust currently. r? @Centril
2019-11-07Rollup merge of #66044 - RalfJung:uninit-lint, r=oli-obkYuki Okushi-0/+1
Improve uninit/zeroed lint * Also warn when creating a raw pointer with a NULL vtable. * Also identify `MaybeUninit::uninit().assume_init()` and `MaybeUninit::zeroed().assume_init()` as dangerous.
2019-11-07Rollup merge of #65794 - Centril:unimpl-internal, r=varkorYuki Okushi-1/+1
gate rustc_on_unimplemented under rustc_attrs Move `rustc_on_implemented` from the `on_implemented` gate to `rustc_attrs` as it is internal. Closes #29628 r? @varkor
2019-11-06Add future incompatibility lint for `array.into_iter()`Lukas Kalbertodt-0/+1
As we might want to add `IntoIterator` impls for arrays in the future, and since that introduces a breaking change, this lint warns and suggests using `iter()` instead (which is shorter and more explicit).
2019-11-06The unsafety in `iter.rs` is already documented wonderfullyOliver Scherer-5/+8
2019-11-06Silence a deprecation warningOliver Scherer-0/+1
2019-11-06Halloween... time to get rid of 👻Oliver Scherer-15/+19
2019-11-06Have tidy ensure that we document all `unsafe` blocks in libcoreOliver Scherer-5/+118
2019-11-06gate rustc_on_unimplemented under rustc_attrsMazdak Farrokhzad-1/+1
2019-11-06Rollup merge of #65973 - eddyb:caller-location-panic, r=petrochenkovMazdak Farrokhzad-17/+15
caller_location: point to macro invocation sites, like file!/line!, and use in core::panic!. The main change here is to `core::panic!`, trying to fix this remaining regression: https://github.com/rust-lang/rust/pull/65927#issuecomment-547625147 However, in order for `caller_location` to be usable from macros the same way `file!()`/`line!()` are, it needs to have the same behavior (of extracting the macro invocation site `Span` and using that). Arguably we would've had to do this at some point anyway, if we want to use `#[track_caller]` to replace the `file!()`/`line!()` uses from macros, but I'm not sure the RFC mentions this at all. r? @petrochenkov cc @anp @nnethercote
2019-11-06Fixed libcore/cell.rs exampleOleg Nosov-1/+4
2019-11-05Apply suggestions from code reviewRalf Jung-2/+2
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-11-05Reverted PhantomData in LinkedList, fixed PhantomData markers in Rc and ArcOleg Nosov-1/+3
2019-11-05Rollup merge of #65948 - danielhenrymantilla:doc/maybe_uninit_ref_mut, ↵Pietro Albini-8/+159
r=RalfJung Improve MaybeUninit::get_{ref,mut} documentation As mentioned in https://github.com/rust-lang/rust/issues/63568#issuecomment-544106668, `MaybeUninit`'s `get_{ref,mut}` documentation is lacking, so this PR attempts to fix that. That being said, and as @RalfJung mentions in that thread, > In particular, we should clarify that all the UB rules for these methods equally apply when calling the raw ptr methods and creating a reference manually. these other docs also need to be improved, which I can do in this PR ~~(hence the `[WIP]`)~~. Finally, since all these documentations are related to clearly establishing when dealing with uninitialized memory which patterns are known to be sound and which patterns are currently UB (that is, until, if ever, the rules around references to unintialized integers get relaxed, this documentation will treat them as UB, and advise against such patterns (_e.g._, it is not possible to use uninitialized buffers with the `Read` API)), I think that adding even more examples to the main documentation of `MaybeUninit` inherent definition wouldn't hurt either. ___ - [Rendered](http://dreamy-ritchie-99d637.netlify.com/core/mem/union.maybeuninit#method.get_ref)
2019-11-05fix link to ptr docsRalf Jung-2/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-01 12:02:23 +0000