about summary refs log tree commit diff
path: root/src/libcore/ffi.rs
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-405/+0
2020-07-10Avoid "whitelist"Tamir Duberstein-1/+1
Other terms are more inclusive and precise.
2020-07-06Expand abbreviation in core::ffi descriptionpierwill-1/+1
2020-06-30Deny unsafe ops in unsafe fns, part 6LeSeulArtichaut-1/+0
And final part!!!
2020-06-30Deny unsafe ops in unsafe fns, part 5LeSeulArtichaut-2/+7
2020-04-23Make VaList::arg link actually workTyler Ruckinger-1/+1
2020-04-23Fix doc link errorsTyler Ruckinger-1/+1
2019-12-21Require issue = "none" over issue = "0" in unstable attributesRoss MacArthur-2/+2
2019-11-26Format libcore with rustfmtDavid Tolnay-119/+164
This commit applies rustfmt with default settings to files in src/libcore *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in `outstanding_files`, the relevant commands were: $ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018 $ rg libcore outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of libcore.
2019-11-06Have tidy ensure that we document all `unsafe` blocks in libcoreOliver Scherer-0/+1
2019-10-29doc: use new feature gate for c_void typeLzu Tao-1/+6
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-38/+18
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-05Revert "Auto merge of #63649 - tlively:emscripten-upstream-upgrade, ↵Tyler Mandry-18/+38
r=alexcrichton" This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
2019-10-04Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-38/+18
- Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the incorrect wasm32 C call ABI with the old asmjs version, which is correct for both wasm32 and JS. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Temporarily makes Emscripten targets use panic=abort by default because supporting unwinding will require an LLVM patch.
2019-07-14Make VaListImpl<'f> invariant over the 'f lifetimeAndrei Homescu-5/+8
2019-07-04Switch master to 1.38Mark Rousskov-6/+0
2019-06-17Expose `VaListImpl` as the Rust equivalent of `__va_list_tag` and implement ↵Andrei Homescu-44/+187
Clone for it.
2019-04-19libcore: deny more...Mazdak Farrokhzad-5/+5
2019-04-18libcore => 2018Taiki Endo-1/+1
2019-03-28Rollup merge of #59371 - dlrobertson:rename_va_list_copy, r=joshtriplettMazdak Farrokhzad-1/+1
ffi: rename VaList::copy to VaList::with_copy Rename `VaList::copy` to `VaList::with_copy` r? @joshtriplett
2019-03-22ffi: rename VaList::copy to VaList::with_copyDan Robertson-1/+1
Rename `VaList::copy` to `VaList::with_copy`.
2019-03-19Fix missing cfg for aarch64 + ios in ffi.rsJames Duley-4/+6
2019-03-19Fix AArch64 typo in commentsJames Duley-1/+1
2019-03-19Fix aarch64 typoJames Duley-2/+2
2019-03-05core: ensure VaList passes improper_ctypes lintDan Robertson-7/+7
Ensure the core::ffi::VaList structure passes the improper_ctypes lint.
2019-02-10libs: doc commentsAlexander Regueiro-2/+2
2019-01-18Rollup merge of #57340 - eqrion:doc/c_variadic, r=Mark-SimulacrumMazdak Farrokhzad-11/+11
Use correct tracking issue for c_variadic Fixes #57306
2019-01-18Rollup merge of #56594 - sdroege:c_void-is-not-never, r=TimNNMazdak Farrokhzad-7/+10
Remove confusing comment about ideally using `!` for `c_void` Using `!` for `c_void` would have the problem that pointers and potentially references to an uninhabited type would be created, and at least for references this is UB. In addition document that newtype wrappers around `c_void` can be used safely in place of `extern type` until the latter is stabilized. ---- I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all? Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](https://github.com/rust-lang/rust/issues/43467) stabilization ticket seems relevant > In [std's](https://github.com/rust-lang/rust/blob/164619a8cfe6d376d25bd3a6a9a5f2856c8de64d/src/libstd/os/raw.rs#L59-L64) source, it is mentioned that LLVM expects i8* for C's void*. > We'd need to continue to hack this for the two c_voids in std and libc. > But perhaps this should be done across-the-board for all extern types? > Somebody should check what Clang does. Please correct me if my understanding is wrong and everything's actually fine as is.
2019-01-07Use correct tracking issue for c_variadicRyan Hunt-11/+11
Fixes #57306
2019-01-03VaList::copy should not require a mutable refDan Robertson-1/+1
VaList::copy does not need to take a mutable reference. The va_copy intrinsic takes a immutable reference.
2018-12-13Update code comments of `c_void` to explain the reasoning for its current ↵Sebastian Dröge-4/+6
implementation We need at least two variants of the enum as otherwise the compiler complains about the #[repr(u8)] attribute and we also need at least one variant as otherwise the enum would be uninhabitated and dereferencing pointers to it would be UB. As such, mark the variants not unstable because they should not actually exist but because they are temporary implementation details until `extern type` is stable and can be used instead.
2018-12-13Remove confusing comment about ideally using `!` for `c_void`Sebastian Dröge-3/+4
Using `!` for `c_void` would have the problem that pointers and potentially references to an uninhabited type would be created, and at least for references this is UB. Also document in addition that newtype wrappers around `c_void` are not recommended for representing opaque types (as a workaround for `extern type` not being stable) but instead refer to the Nomicon.
2018-12-12Bump to 1.33.0Alex Crichton-4/+0
* Update bootstrap compiler * Update version to 1.33.0 * Remove some `#[cfg(stage0)]` annotations Actually updating the version number is blocked on updating Cargo
2018-12-08Rollup merge of #56599 - dlrobertson:fix_va_arg, r=eddybMazdak Farrokhzad-0/+2
codegen: Fix va_list - aarch64 iOS/Windows ## Summary Fix code generated for `VaList` on Aarch64 iOS/Windows. ## Details According to the [Apple - ARM64 Function Calling Conventions]: > ... the type va_list is an alias for char * rather than for the struct > type specified in the generic PCS. The current implementation uses the generic Aarch64 structure for `VaList` for Aarch64 iOS. Switch to using the `char *` variant of the `VaList` and use the corresponding `emit_ptr_va_arg` for the `va_arg` intrinsic. Windows always uses the `char *` variant of the `VaList`. Update the `va_arg` intrinsic to use `emit_ptr_va_arg`. [Apple - ARM64 Function Calling Conventions]: https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
2018-12-07Various minor/cosmetic improvements to codeAlexander Regueiro-1/+1
2018-12-07codegen: Fix va_list - aaarch64 iOS/WindowsDan Robertson-0/+2
According to the Apple developer docs: > The type va_list is an alias for char * rather than for the struct > type specified in the generic PCS. The current implementation uses the generic Aarch64 structure for VaList for Aarch64 iOS. Windows always uses the char * variant of the va_list.
2018-11-26libcore: Add va_list lang item and intrinsicsDan Robertson-0/+185
- Add the llvm intrinsics used to manipulate a va_list. - Add the va_list lang item in order to allow implementing VaList in libcore.
2018-09-14Move std::os::raw::c_void into libcore and re-export in libstdIsaac Woods-0/+42