profile
viewpoint

Amanieu/asyncplusplus 818

Async++ concurrency framework for C++11

Amanieu/intrusive-rs 204

Intrusive collections for Rust

Amanieu/atomic-rs 98

Generic Atomic<T> type for Rust

Amanieu/hashbrown 29

Rust port of Google's SwissTable hash map

Amanieu/hashmap_core 20

Implementation of HashMap and HashSet for no_std environments

Amanieu/cstr_core 18

Implementation of CStr and CString for no_std environments

Amanieu/cbeardy 6

A markov chain generator written in C.

Amanieu/format 1

Lightweight printf-compatible format processing library

Amanieu/arrayvec 0

A vector with a fixed capacity. (Rust)

Amanieu/benchmarks 0

Some benchmarks of different languages

pull request commentrust-lang/hashbrown

Reverse `drain_filter` behavior to match libstd

@bors r+

mbrubeck

comment created time in 7 hours

pull request commentrust-lang/hashbrown

Reverse `drain_filter` behavior to match libstd

@bors r+

mbrubeck

comment created time in 7 hours

issue commentrust-lang/hashbrown

`drain_filter` has opposite behavior of standard library version

That... seems unfortunate. I assume the proper behavior is the one in libstd and the behavior of hashbrown is incorrect.

This is going to have to be a (silent) breaking change, but that's fine since we can just do a major version bump.

mbrubeck

comment created time in 8 hours

push eventrust-lang/hashbrown

Deployment Bot (from Travis CI)

commit sha ef65ecfe1eb7a92141db1e0884ac662bf9b5f239

Deploy rust-lang/hashbrown to github.com/rust-lang/hashbrown.git:gh-pages

view details

push time in 8 hours

pull request commentrust-lang/hashbrown

Relax bounds on HashSet constructors

@bors r+

mbrubeck

comment created time in 8 hours

pull request commentrust-lang/rust

Let compiler assume, that `Layout::align()` is always a power of two

I'm personally tending towards closing this PR. I don't think we should be complicating the code with optimizations that don't actually improve performance in practice.

TimDiekmann

comment created time in 8 hours

pull request commentAmanieu/cstr_core

alloc is now stable (fixes #4)

Thanks!

joseluis

comment created time in 11 hours

push eventAmanieu/cstr_core

joseLuís

commit sha c20ecd7794d17314a250f62abae9efb0f0519ab2

alloc is now stable (fixes #4)

view details

Amanieu d'Antras

commit sha e2a2fbf1a870107bf45419bed6a608d7ae467322

Merge pull request #13 from joseluis/stable-alloc

view details

push time in 11 hours

issue closedAmanieu/cstr_core

Allow compilation on stable toolchain.

The crate enables the alloc feature via #![cfg_attr(feature = "alloc", feature(alloc))] and can therefore not be compiled via stable toolchain.

As the feature was stabilized ~1 year ago would it be possible to remove this line or is there another way to extend cfg_attr to check the compiler version in use?

closed time in 11 hours

0ndorio

PR merged Amanieu/cstr_core

alloc is now stable (fixes #4)

Rust 1.36 stabilized the alloc crate more than a year ago. Therefore it is not longer needed to check for the alloc feature which effectively denied the use of CString in the stable compiler.

+1 -1

4 comments

1 changed file

joseluis

pr closed time in 11 hours

pull request commentAmanieu/cstr_core

alloc is now stable (fixes #4)

I think you should keep the alloc feature as it is and just add it to the list of default features for the crate.

joseluis

comment created time in 19 hours

pull request commentAmanieu/cstr_core

alloc is now stable (fixes #4)

The alloc is still useful for people who want to compile with pure libcore without a global allocator. However since this is such a nice case we can probably enable alloc by default.

joseluis

comment created time in 20 hours

pull request commentrust-lang/rust

Add PartialEq impls for Vec <-> slice

@rfcbot fcp merge

mbrubeck

comment created time in a day

push eventrust-lang/stdarch

Lokathor

commit sha ac684c46237941760b9353c39a90894f09481d7e

add more things that do adds (#881) Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>

view details

push time in a day

PR merged rust-lang/stdarch

add more things that do adds

I'm doing this on an arm32 device so I've already run all those tests and squared that away, but for arm64 we'll have to rely on the CI.

  • The last two "add"
  • "add across vector" (aka horizontal add)
  • "add pairwise"
+489 -6

6 comments

4 changed files

Lokathor

pr closed time in a day

Pull request review commentrust-lang/stdarch

add more things that do adds

 extern "C" {     #[link_name = "llvm.aarch64.neon.pmull64"]     fn vmull_p64_(a: i64, b: i64) -> int8x16_t; +    #[link_name = "llvm.aarch64.neon.addp.v8i16"]+    fn vpaddq_s16_(a: int16x8_t, b: int16x8_t) -> int16x8_t;+    #[link_name = "llvm.aarch64.neon.addp.v4i32"]+    fn vpaddq_s32_(a: int32x4_t, b: int32x4_t) -> int32x4_t;     #[link_name = "llvm.aarch64.neon.addp.v16i8"]-    fn vpaddq_u8_(a: uint8x16_t, b: uint8x16_t) -> uint8x16_t;+    fn vpaddq_s8_(a: int8x16_t, b: int8x16_t) -> int8x16_t;+    +    #[link_name = "llvm.aarch64.neon.saddv.i32.v4i16"]+    fn vaddv_s16_(a: int16x4_t) -> i16;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v2i32"]+    fn vaddv_s32_(a: int32x2_t) -> i32;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v8i8"]+    fn vaddv_s8_(a: int8x8_t) -> i8;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v4i16"]+    fn vaddv_u16_(a: uint16x4_t) -> u16;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v2i32"]+    fn vaddv_u32_(a: uint32x2_t) -> u32;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v8i8"]+    fn vaddv_u8_(a: uint8x8_t) -> u8;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v8i16"]+    fn vaddvq_s16_(a: int16x8_t) -> i16;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v4i32"]+    fn vaddvq_s32_(a: int32x4_t) -> i32;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v16i8"]+    fn vaddvq_s8_(a: int8x16_t) -> i8;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v8i16"]+    fn vaddvq_u16_(a: uint16x8_t) -> u16;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v3i32"]
    #[link_name = "llvm.aarch64.neon.uaddv.i32.v4i32"]
Lokathor

comment created time in 2 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

There is a register involved to hold the address you want to perform a bit test on.

Amanieu

comment created time in 2 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

It does work if you wrap it in [] to indicate a memory operand.

Amanieu

comment created time in 2 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

By passing the address in as a register operand.

Amanieu

comment created time in 2 days

pull request commentrust-lang/rust

Update hashbrown to 0.8.2

cc @nnethercote

Amanieu

comment created time in 2 days

pull request commentrust-lang/rust

Update hashbrown to 0.8.2

@bors rollup=never

Amanieu

comment created time in 2 days

PR opened rust-lang/rust

Update hashbrown to 0.8.2

Includes:

  • Avoid closures to improve compile times (https://github.com/rust-lang/hashbrown/pull/183)
  • Do not iterate to drop if empty (https://github.com/rust-lang/hashbrown/pull/182)

r? @Mark-Simulacrum

+3 -3

0 comment

1 changed file

pr created time in 2 days

issue commentAmanieu/parking_lot

lock_api nightly feature

It's because there are restrictions on const fn functions with generic bounds, which means that those functions do not compile on stable.

coolreader18

comment created time in 2 days

issue commentrust-lang/stdarch

Implement AVX-512 intrinsics

I suggest using a debugger to look at the disassembly of the crashing code.

alexcrichton

comment created time in 3 days

pull request commentrust-lang/rust

Let compiler assume, that `Layout::align()` is always a power of two

I don't think we gain anything from this: in the standard library we are careful to always use from_size_align_unchecked when dealing with alignment that are known to be a power of 2 to avoid the extra check. And at this point I don't think anyone is using Layout outside of the standard library.

TimDiekmann

comment created time in 3 days

pull request commentrust-lang/stdarch

add more things that do adds

cc @alexcrichton for the WASI CI failure

Lokathor

comment created time in 3 days

create barnchAmanieu/rust

branch : hashbrown8

created branch time in 3 days

push eventrust-lang/hashbrown

Deployment Bot (from Travis CI)

commit sha 4e8b901776c4ba731aa3b95fc9ed4ab539b70ea7

Deploy rust-lang/hashbrown to github.com/rust-lang/hashbrown.git:gh-pages

view details

push time in 3 days

created tagrust-lang/hashbrown

tagv0.8.2

Rust port of Google's SwissTable hash map

created time in 3 days

push eventrust-lang/hashbrown

Amanieu d'Antras

commit sha 18ea4fe99a9509b916a246bb0adbedcc47d80e01

Version 0.8.2

view details

push time in 3 days

pull request commentrust-lang/stdarch

add more things that do adds

Yes, you can just delete the vec_leak feature.

Lokathor

comment created time in 3 days

Pull request review commentrust-lang/stdarch

add more things that do adds

 extern "C" {     #[link_name = "llvm.aarch64.neon.pmull64"]     fn vmull_p64_(a: i64, b: i64) -> int8x16_t; +    #[link_name = "llvm.aarch64.neon.addp.v8i16"]+    fn vpaddq_s16_(a: int16x8_t, b: int16x8_t) -> int16x8_t;+    #[link_name = "llvm.aarch64.neon.addp.v4i32"]+    fn vpaddq_s32_(a: int32x4_t, b: int32x4_t) -> int32x4_t;     #[link_name = "llvm.aarch64.neon.addp.v16i8"]-    fn vpaddq_u8_(a: uint8x16_t, b: uint8x16_t) -> uint8x16_t;+    fn vpaddq_s8_(a: int8x16_t, b: int8x16_t) -> int8x16_t;+    #[link_name = "llvm.aarch64.neon.uaddv.i64.v2i64"]+    fn vpaddd_s64_(a: int64x2_t) -> i64;+    +    +    #[link_name = "llvm.aarch64.neon.saddv.i32.v4i16"]+    fn vaddv_s16_(a: int16x4_t) -> i16;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v2i32"]+    fn vaddv_s32_(a: int32x2_t) -> i32;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v8i8"]+    fn vaddv_s8_(a: int8x8_t) -> i8;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v4i16"]+    fn vaddv_u16_(a: uint16x4_t) -> u16;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v2i32"]+    fn vaddv_u32_(a: uint32x2_t) -> u32;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v8i8"]+    fn vaddv_u8_(a: uint8x8_t) -> u8;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v8i16"]+    fn vaddvq_s16_(a: int16x8_t) -> i16;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v4i32"]+    fn vaddvq_s32_(a: int32x4_t) -> i32;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v16i8"]+    fn vaddvq_s8_(a: int8x16_t) -> i8;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v8i16"]+    fn vaddvq_u16_(a: uint16x8_t) -> u16;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v3i32"]+    fn vaddvq_u32_(a: uint32x4_t) -> u32;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v16i8"]+    fn vaddvq_u8_(a: uint8x16_t) -> u8;+    #[link_name = "llvm.aarch64.neon.saddv.i32.v2i64"]+    fn vaddvq_s64_(a: int64x2_t) -> i64;+    #[link_name = "llvm.aarch64.neon.uaddv.i32.v2i64"]+    fn vaddvq_u64_(a: uint64x2_t) -> u64;

Are you sure about the .i32 in these? It seems to me that this should be the return type of the intrinsic.

Lokathor

comment created time in 3 days

push eventrust-lang/hashbrown

Deployment Bot (from Travis CI)

commit sha a2678b7e76484aa216458338522cee88cff0c4a3

Deploy rust-lang/hashbrown to github.com/rust-lang/hashbrown.git:gh-pages

view details

push time in 3 days

delete branch Amanieu/hashbrown

delete branch : rawiter_rules

delete time in 3 days

push eventrust-lang/hashbrown

Amanieu d'Antras

commit sha 845b0f0a41db4fec61ca7107917bac3a4c0c5b57

Document RawIter guarantees Fixes #165

view details

Amanieu d'Antras

commit sha 4c557148859cc01f5914133653bd3176fc6562bd

Merge pull request #184 from Amanieu/rawiter_rules Document RawIter guarantees

view details

push time in 3 days

PR merged rust-lang/hashbrown

Document RawIter guarantees

Fixes #165

cc @CAD97 @jonhoo

+11 -0

0 comment

1 changed file

Amanieu

pr closed time in 3 days

issue closedrust-lang/hashbrown

Doc request: what modification is allowed to RawTable while holding RawIter

More context on urlo and my questionable code.

What operations are allowed on RawTable while holding a RawIter?

Per my reading, the implementation currently suggests:

  • Required(?) for exposed behavior:
    • non-mutating inspection of the RawTable
    • eraseing the most recently yielded Bucket
  • Definitely not allowed (UB):
    • anything that causes a reallocation
    • erasing a bucket "ahead" of the iterator that has yet to be yielded
  • Potentially allowed:
    • erasing a bucket "behind" the iterator head that has previously been yielded but is not the most recently yielded bucket

I would benefit from the above "delayed erasing" being guaranteed sound (for the use case linked above).

Side note: it would be useful to make RawIter's debug_assert that it iterated all the expected items say what went wrong. Something simple like "exhausted iterator before expected; this likely indicates modification of a hash table while iterating it, which is UB" would definitely make hitting that assertion more obvious than the default message of "200 != 0" from inside of hashbrown's internals.

closed time in 3 days

CAD97

pull request commentrust-lang/hashbrown

Avoid closures to improve compile times.

Sure, I'll do that after #184 is merged.

nnethercote

comment created time in 3 days

PR opened rust-lang/hashbrown

Document RawIter guarantees

Fixes #165

cc @CAD97 @jonhoo

+11 -0

0 comment

1 changed file

pr created time in 3 days

create barnchAmanieu/hashbrown

branch : rawiter_rules

created branch time in 3 days

issue closedrust-lang/hashbrown

Document erase_no_drop guarantees

Following some discussion in https://github.com/bluss/indexmap/pull/131#discussion_r447965041, it'd be good to document the contract of erase_no_drop. In particular, there is code both inside hashbrown and in the pending PR to indexmap (https://github.com/bluss/indexmap/pull/131) along the lines of:

let v = unsafe {
    table.erase_no_drop(&bucket);
    bucket.read()
}

This, by first reading, seems like it shouldn't be okay. erase_no_drop erases the bucket, so why is it okay to read from it after the fact? It turns out, probably unsurprisingly, that hashbrown indeed currently supports this sequence of operations; erase only erases the bucket in the control bytes, but does not otherwise invalidate the bucket.

I think we have a choice to make: either we add this as a guarantee to the documentation of erase_no_drop so that callers can rely on that detail of the implementation, or we do not give that guarantee, and require callers to always access the bucket before they erase it. The latter gives us more leeway to change erase_no_drop later, at the cost of slightly less convenient access for callers. Of course internally it's fine for hashbrown to rely on being able to access the bucket after erase_no_drop is called. This is a question of what the public contract (which we cannot break without a breaking release) should be.

closed time in 3 days

jonhoo

issue commentrust-lang/hashbrown

Document erase_no_drop guarantees

erase_no_drop is deprecated and replaced by erase and remove so I'm going to close this.

jonhoo

comment created time in 3 days

pull request commentrust-lang/rust

[android] Add support for android's file descriptor ownership tagging to libstd.

Undefined behavior doesn't have to be linked to the compiler, it can come from the library as well: in this case it means that behavior may change in the future and may lead to unsoundness via unsafe assumptions (i.e. writing to the wrong FD).

I think that undefined behavior is appropriate in this case: Android happens to catch these cases, but other platforms do not.

jmgao

comment created time in 3 days

Pull request review commentrust-lang/rfcs

Constrained Naked Functions

+- Feature Name: `constrained_naked`+- Start Date: 2020-08-06+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+This document attempts to increase the utility of [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md) by constraining their use and increasing their defined invariants. This document also defines a new calling convention: `extern "custom"`.++# Motivation++Naked functions have long been a feature of compilers. These functions are typically defined as normal functions in every regard, except that the compiler does not emit the function prologue and epilogue. Rust's early attempt to support this feature ([RFC 1201](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md)) mostly copied the existing compiler behaviors.++However, naked functions are often avoided in practice because their behavior is not well defined. The root cause of this problem is that naked functions are defined by negation: they are functions which lack a prologue and epilogue. Unfortunately, functions that lack a prologue and epilogue present a number of complicated problems that the compiler needs to solve and developers need to work around. And there is a long history of compilers and developers getting this wrong.++This document seeks to define naked functions in a much more constrained, positivistic way. In doing so, naked functions can become more useful.++# Naked function definition++A naked function is a type of FFI function with a defined calling convention and a body which contains only assembly code which can rely upon the defined calling convention.++A naked function is identified by the `#[naked]` attribute and:+1. must specify a calling convention besides `extern "Rust"`.+1. must define only FFI-safe arguments and return types.+1. must not specify the `#[inline]` or `#[inline(always)]` attribute.+1. must have a body which contains only a single `asm!()` statement which:+    1. may be wrapped in an `unsafe` block.+    1. must not contain any operands except `const` or `sym`.+    1. must contain the `noreturn` option.+    1. must not contain any other options except `att_syntax`.+    1. must ensure that the requirements of the calling convention are followed.++In exchange for the above constraints, the compiler commits to:+1. produce a clear error if any of the above rules are violated.+1. never inline the function (implicit `#[inline(never)]`).+1. emit no instructions to the function body that are not contained in the `asm!()` statement.++As a (weaker) correlary to the last compiler commitment, since the compiler generates no additional instructions, the initial state of all registers in the `asm!()` statement conform to the specified calling convention.++# Custom Calling Convention++In order to expand the usefulness of naked functions, this document also define a new calling convention, `extern "custom"`, that can be used only with naked functions. Functions with `extern "custom"` are not callable from Rust and must be marked as`unsafe`. The function definition must contain no arguments or return type. For example:

I feel that this is over-extending the scope of the RFC. Simple newtype wrappers around an extern "custom" function pointer are enough to build type-safe abstractions, there is no need to add complexity to the language for such a niche feature.

Regarding unsafe, it really doesn't make a difference in practice since the only difference between a fn and unsafe fn is that the latter can only be called from within an unsafe block. This doesn't apply to extern "custom" since it can't be called from Rust at all.

npmccallum

comment created time in 4 days

pull request commentrust-lang/rust

Don't call a function in function-arguments-naked.rs

@bors r+ rollup

Aaron1011

comment created time in 4 days

Pull request review commentrust-lang/rfcs

Constrained Naked Functions

+- Feature Name: `constrained_naked`+- Start Date: 2020-08-06+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+This document attempts to increase the utility of [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md) by constraining their use and increasing their defined invariants. This document also defines a new calling convention: `extern "custom"`.++# Motivation++Naked functions have long been a feature of compilers. These functions are typically defined as normal functions in every regard, except that the compiler does not emit the function prologue and epilogue. Rust's early attempt to support this feature ([RFC 1201](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md)) mostly copied the existing compiler behaviors.++However, naked functions are often avoided in practice because their behavior is not well defined. The root cause of this problem is that naked functions are defined by negation: they are functions which lack a prologue and epilogue. Unfortunately, functions that lack a prologue and epilogue present a number of complicated problems that the compiler needs to solve and developers need to work around. And there is a long history of compilers and developers getting this wrong.++This document seeks to define naked functions in a much more constrained, positivistic way. In doing so, naked functions can become more useful.++# Naked function definition++A naked function is a type of FFI function with a defined calling convention and a body which contains only assembly code which can rely upon the defined calling convention.++A naked function is identified by the `#[naked]` attribute and:+1. must specify a calling convention besides `extern "Rust"`.+1. must define only FFI-safe arguments and return types.+1. must not specify the `#[inline]` or `#[inline(always)]` attribute.+1. must have a body which contains only a single `asm!()` statement which:+    1. may be wrapped in an `unsafe` block.+    1. must not contain any operands except `const` or `sym`.+    1. must contain the `noreturn` option.+    1. must not contain any other options except `att_syntax`.+    1. must ensure that the requirements of the calling convention are followed.++In exchange for the above constraints, the compiler commits to:+1. produce a clear error if any of the above rules are violated.+1. never inline the function (implicit `#[inline(never)]`).+1. emit no instructions to the function body that are not contained in the `asm!()` statement.++As a (weaker) correlary to the last compiler commitment, since the compiler generates no additional instructions, the initial state of all registers in the `asm!()` statement conform to the specified calling convention.++# Custom Calling Convention++In order to expand the usefulness of naked functions, this document also define a new calling convention, `extern "custom"`, that can be used only with naked functions. Functions with `extern "custom"` are not callable from Rust and must be marked as`unsafe`. The function definition must contain no arguments or return type. For example:

I don't see why we should require such functions to be unsafe. They can't be called by Rust code at all so it shouldn't matter whether they are safe or unsafe.

npmccallum

comment created time in 4 days

Pull request review commentrust-lang/rfcs

Constrained Naked Functions

+- Feature Name: `constrained_naked`+- Start Date: 2020-08-06+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+This document attempts to increase the utility of [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md) by constraining their use and increasing their defined invariants. This document also defines a new calling convention: `extern "custom"`.++# Motivation++Naked functions have long been a feature of compilers. These functions are typically defined as normal functions in every regard, except that the compiler does not emit the function prologue and epilogue. Rust's early attempt to support this feature ([RFC 1201](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md)) mostly copied the existing compiler behaviors.++However, naked functions are often avoided in practice because their behavior is not well defined. The root cause of this problem is that naked functions are defined by negation: they are functions which lack a prologue and epilogue. Unfortunately, functions that lack a prologue and epilogue present a number of complicated problems that the compiler needs to solve and developers need to work around. And there is a long history of compilers and developers getting this wrong.++This document seeks to define naked functions in a much more constrained, positivistic way. In doing so, naked functions can become more useful.++# Naked function definition++A naked function is a type of FFI function with a defined calling convention and a body which contains only assembly code which can rely upon the defined calling convention.++A naked function is identified by the `#[naked]` attribute and:+1. must specify a calling convention besides `extern "Rust"`.+1. must define only FFI-safe arguments and return types.

This should also be a lint rather than a hard error.

npmccallum

comment created time in 4 days

Pull request review commentrust-lang/rfcs

Constrained Naked Functions

+- Feature Name: `constrained_naked`+- Start Date: 2020-08-06+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+This document attempts to increase the utility of [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md) by constraining their use and increasing their defined invariants. This document also defines a new calling convention: `extern "custom"`.++# Motivation++Naked functions have long been a feature of compilers. These functions are typically defined as normal functions in every regard, except that the compiler does not emit the function prologue and epilogue. Rust's early attempt to support this feature ([RFC 1201](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md)) mostly copied the existing compiler behaviors.++However, naked functions are often avoided in practice because their behavior is not well defined. The root cause of this problem is that naked functions are defined by negation: they are functions which lack a prologue and epilogue. Unfortunately, functions that lack a prologue and epilogue present a number of complicated problems that the compiler needs to solve and developers need to work around. And there is a long history of compilers and developers getting this wrong.++This document seeks to define naked functions in a much more constrained, positivistic way. In doing so, naked functions can become more useful.++# Naked function definition++A naked function is a type of FFI function with a defined calling convention and a body which contains only assembly code which can rely upon the defined calling convention.++A naked function is identified by the `#[naked]` attribute and:+1. must specify a calling convention besides `extern "Rust"`.+1. must define only FFI-safe arguments and return types.+1. must not specify the `#[inline]` or `#[inline(always)]` attribute.+1. must have a body which contains only a single `asm!()` statement which:+    1. may be wrapped in an `unsafe` block.+    1. must not contain any operands except `const` or `sym`.+    1. must contain the `noreturn` option.+    1. must not contain any other options except `att_syntax`.+    1. must ensure that the requirements of the calling convention are followed.++In exchange for the above constraints, the compiler commits to:+1. produce a clear error if any of the above rules are violated.+1. never inline the function (implicit `#[inline(never)]`).+1. emit no instructions to the function body that are not contained in the `asm!()` statement.

Currently LLVM will insert a ud2 instruction after the assembly code because of https://github.com/rust-lang/rust/pull/45920. That's not a big issue in practice because we're only adding instructions after the asm rather than before it.

npmccallum

comment created time in 4 days

Pull request review commentrust-lang/rfcs

Constrained Naked Functions

+- Feature Name: `constrained_naked`+- Start Date: 2020-08-06+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+This document attempts to increase the utility of [naked functions](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md) by constraining their use and increasing their defined invariants. This document also defines a new calling convention: `extern "custom"`.++# Motivation++Naked functions have long been a feature of compilers. These functions are typically defined as normal functions in every regard, except that the compiler does not emit the function prologue and epilogue. Rust's early attempt to support this feature ([RFC 1201](https://github.com/rust-lang/rfcs/blob/master/text/1201-naked-fns.md)) mostly copied the existing compiler behaviors.++However, naked functions are often avoided in practice because their behavior is not well defined. The root cause of this problem is that naked functions are defined by negation: they are functions which lack a prologue and epilogue. Unfortunately, functions that lack a prologue and epilogue present a number of complicated problems that the compiler needs to solve and developers need to work around. And there is a long history of compilers and developers getting this wrong.++This document seeks to define naked functions in a much more constrained, positivistic way. In doing so, naked functions can become more useful.++# Naked function definition++A naked function is a type of FFI function with a defined calling convention and a body which contains only assembly code which can rely upon the defined calling convention.++A naked function is identified by the `#[naked]` attribute and:+1. must specify a calling convention besides `extern "Rust"`.

This should be a lint rather than a hard error. I can think of a use case for "Rust" calling convention where you forward to another function with just a jmp instruction.

npmccallum

comment created time in 4 days

Pull request review commentrust-lang/rust

Don't call a function in function-arguments-naked.rs

 fn main() {  #[naked] fn naked(x: usize, y: usize) {
extern "C" fn naked(x: usize, y: usize) {

Some calling conventions (e.g. stdcall) require a stack adjustment on return. Since the Rust calling convention is unspecified, it's better to explicitly use "C".

Aaron1011

comment created time in 4 days

pull request commentrust-lang/rust

Don't call a function in function-arguments-naked.rs

It is also UB to not have anything in a naked function. You need an asm! since #[naked] will not emit a return instruction for you.

Aaron1011

comment created time in 4 days

push eventrust-lang/hashbrown

Deployment Bot (from Travis CI)

commit sha 66167f2d5a2dbaf9098deed721083c11261621c7

Deploy rust-lang/hashbrown to github.com/rust-lang/hashbrown.git:gh-pages

view details

push time in 4 days

pull request commentrust-lang/hashbrown

Avoid closures to improve compile times.

@bors r+

nnethercote

comment created time in 4 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

Discussion on naked functions should probably continue on one of these:

  • #[naked] tracking issue #32408
  • https://github.com/rust-lang/rfcs/pull/2774 a PR to update the naked function RFC.
Amanieu

comment created time in 4 days

pull request commentrust-lang/rust

Update hashbrown to 0.8.1

@bors r=Mark-Simulacrum

Amanieu

comment created time in 4 days

push eventAmanieu/rust

Caio

commit sha 187aea7c34adf06b0db39f688d60d3fdac8e7e3e

Impl Default for ranges

view details

flip1995

commit sha f7acea2683c6124854bfe20e7127e4dfba344d3e

Register redundant_field_names and non_expressive_names as early passes

view details

flip1995

commit sha 485229c4a3d6a2fbe40f5a6976a33144a27497c6

Fix fallout in redundant_field_names

view details

flip1995

commit sha efd3dcff97f67f376e354c047133ce9044c52991

Fix fallout in similar_names

view details

Eduardo Broto

commit sha bb37a0f948b02e6434dbe3ea615960052d37f784

Avoid triggering similar names on code from expansion

view details

Alexis Bourget

commit sha 2853448426ce76926baa7e6e6173c15228e4951a

Document the ref keyword

view details

Stefan Lankes

commit sha 6813c1c69baf870a479c70e23ad0550d1d9aa9be

revise RwLock, which is derived from the wasm implementation - increasing the readability of `Condvar` - simplify the interface to the libos HermitCore

view details

Stefan Lankes

commit sha 3acc3ef10d2099a4b3118e8c705b36f4bbaf6f64

minor changes to pass the format check

view details

Stefan Lankes

commit sha beb1b1fa5b1047c7caf8a1d499725df3c1ad8cad

reorder crates to pass the format check

view details

Stefan Lankes

commit sha f9c609164251abc136eb9bda55c92cb99adb5c86

remove some compiler warnings

view details

Trevor Spiteri

commit sha 6dfe144bdd4413ac55cbb2ad2edfb1daa0c4bf15

stabilize const_nonzero_int_methods

view details

Trevor Spiteri

commit sha 9739b512a892628534e730ffcd9756b3218c8de8

stabilize some const_checked_int_methods

view details

Trevor Spiteri

commit sha c1c674c2dbfe3f6dc47d11368c1b5ee4ab008799

stabilize const_saturating_int_methods

view details

Trevor Spiteri

commit sha 056d925167318636fcf975c8ffb81efebdc9bca3

stabilize const_int_sign

view details

Trevor Spiteri

commit sha 2a84e313df095fd0e81b9348b68bd9b1d1caa551

stabilize const_ascii_ctype_on_intrinsics

view details

Adam Perry

commit sha d275739c09f266479d6db388cbf55ba6ca791b9d

Derive common traits for panic::Location. Add documentation about the host/target behavior of Location::file.

view details

Jamie Cunliffe

commit sha fc52b47e8013da325fc0a0f5d3897143243ba206

va_args implementation for AAPCS. Implement the va args in codegen for AAPCS, this will be used as the default va_args implementation for AArch64 rather than the va_args llvm-ir as it currently is. Copyright (c) 2020, Arm Limited.

view details

Alexis Bourget

commit sha 837a761b398a6ff6a97f7f61e390dae9efbeab79

Document the where keyword

view details

Andrey Zgarbul

commit sha 7d4a92d4f8dc03409984695d78893fffdd3ff1f9

remove LengthAtMost32 on AsRef/Borrow impl for array

view details

Roman Proskuryakov

commit sha eff62069ad602090e8d27b83cffd9e77479ed4be

Remove the usage of the LengthAtMost32 trait

view details

push time in 4 days

issue commentrust-lang/rust

Tracking issue for stable SIMD in Rust

Only AArch64 has 2x64-bit LL/SC.

alexcrichton

comment created time in 4 days

issue commentrust-lang/rust

Tracking issue for stable SIMD in Rust

AtomicU128 will only be available on targets that support it. AFAIK that's only x86_64 and AArch64.

alexcrichton

comment created time in 4 days

created tagAmanieu/atomic-rs

tagv0.5.0

Generic Atomic<T> type for Rust

created time in 4 days

push eventAmanieu/atomic-rs

Amanieu d'Antras

commit sha 5803aec0f3636792058ca8493fd482fbad4ba8ed

Bump version to 0.5.0

view details

push time in 4 days

push eventAmanieu/atomic-rs

M Farkas-Dyck

commit sha 44c9d899b4bb9acaae1ca012a1ab574cc7f61718

repr(transparent)

view details

Amanieu d'Antras

commit sha 31ed6069234113d7fc2bc5feac1773c9a9102a8f

Merge branch 'master' into transparent

view details

Amanieu d'Antras

commit sha 64bd54252f650b013106aa77d16973af86b1fbeb

Merge pull request #4 from strake/transparent

view details

push time in 4 days

PR merged Amanieu/atomic-rs

repr(transparent)
+1 -0

2 comments

1 changed file

strake

pr closed time in 4 days

push eventstrake/atomic.rs

MSxDOS

commit sha 2def863339b007317054e3febb3cb5fb076efb4b

Add 'get_mut' and 'into_inner' methods

view details

MSxDOS

commit sha 13bf2ba36c36b185adbc0003a77f66316b07960d

Fix description

view details

Amanieu d'Antras

commit sha fb478e9da0f3ee6d73c481dba9906b68bc1abbab

Merge pull request #9 from MSxDOS/master Add 'get_mut' and 'into_inner' methods

view details

Amanieu d'Antras

commit sha 1faf633024a3aa93f03b12192efd7c2fabd1e8d6

Bump version to 0.4.5

view details

Hadrien G

commit sha 973c055f82e75dd8b78912ab9b3f873471d7919c

Provide a RefUnwindSafe implementation when 'std' feature is enabled

view details

Hadrien G

commit sha b8b900f26bdaa9746b9a9c70539eb5429ca524d2

Apply review recommendations

view details

Amanieu d'Antras

commit sha f0862e4248f516fc5dd38ab4c159ccc9b30e8441

Merge pull request #11 from HadrienG2/ref-unwind-safe Provide a RefUnwindSafe implementation when 'std' feature is enabled

view details

Jasen Borisov

commit sha e9ee099123e4ae61ef9c2ab5f57188950ae64383

ops.rs: fix compiler error from missing imports only import the types that are supported by the compile target

view details

Amanieu d'Antras

commit sha 107428ed098b80bfd2e2086e3ac8c9ede22dbd85

Merge pull request #13 from jamadazi/fix-imports ops.rs: fix compiler error from missing imports

view details

Amanieu d'Antras

commit sha e52d9075341c4421f492e9c49a05b48068d8bb54

Bump version to 0.4.6

view details

Adam Reichold

commit sha 7db30b4f1ba1b7953023734ae20cb5ba34c120a9

Port the fetch_update implementation from the standard library.

view details

Amanieu d'Antras

commit sha d5e1015fc5ba50e238c08674c7ea9c2971671a51

Merge pull request #16 from adamreichold/fetch-update Port the fetch_update implementation from the standard library.

view details

Adam Reichold

commit sha df02842847bad2cd50ef43c47ab7e9cbdb6f6b85

Replace use of unstable features by use of autocfg Instead of using unstable features, this detects the availability of the various atomic types using the autocfg crate by dynamically compiling code snippets via the build script. This still raises the MSRV however as const functions Atomic::new and Atomic::is_lock_free cannot be defined below Rust 1.31.0.

view details

Adam Reichold

commit sha ceba87603f43965d52f3011898d02363482970ce

Bump MSRV to 1.45.0 and therefore remove the has_fetch_min configuration flag.

view details

Adam Reichold

commit sha 833996f2b9c31a2f3851f8ad0f497a0f76bbc2fe

Remove fallback to word-sized atomics as we explicitly detect the available atomics now.

view details

Adam Reichold

commit sha 756aa4624bcecf2f0149119a991045545713cbbb

Add detection and usage of 128 bit atomic integers.

view details

Amanieu d'Antras

commit sha b9020a51a46572602297f0893da011803f5dca21

Merge pull request #15 from adamreichold/drop-nightly-bump-msrv

view details

Adam Reichold

commit sha 35579fc88bfc34438054b646ee81695ccc61dc69

Upgrade to Rust edition 2018.

view details

Amanieu d'Antras

commit sha 34f48f5be15abcecfd14fad5312bb16b89d7954c

Merge pull request #18 from adamreichold/upgrade-to-edition-2018 Upgrade to Rust edition 2018

view details

Adam Reichold

commit sha 0932d0fd57e3ea0f0d7d18389129dbad77407816

Make fallback implementation optional to increase confidence in performance characteristics.

view details

push time in 4 days

PR opened rust-lang/rust

Update asm! documentation in unstable book
  • Update the list of supported architectures.
  • Clarify issues with LLVM's use of reserved registers.
+13 -1

0 comment

1 changed file

pr created time in 4 days

create barnchAmanieu/rust

branch : asm_unstable_book

created branch time in 4 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

Possible, yes, but only by changing LLVM, since LLVM IR module-level assembly doesn't support operands and the alternative of pasting symbol names into the asm string wouldn't be sufficient to tell LLVM the target symbols must not be dead-code-eliminated.

It's just a matter of marking any symbols referenced by global_asm! as #[used].

Amanieu

comment created time in 4 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

Adding support for a new architecture is actually quite straightforward since most of the work is already done in LLVM. You only need to make 2 changes:

  • Add the register definitions to src/librustc_target/asm/.
  • Add lowering to LLVM asm to src/librustc_codegen_llvm/asm.rs.

Have a look at #73214 which added inline asm support for Hexagon.

Amanieu

comment created time in 4 days

pull request commentrust-lang/rust

Fix ICE when using asm! on an unsupported architecture

The list of supported target is in the unstable book. It's a bit out of date so I will make another PR to update it.

Amanieu

comment created time in 5 days

issue commentrust-lang/rust

1.45.0 regression asm-related ICE in tests on non-x86

Fixed by #75227.

infinity0

comment created time in 5 days

PR opened rust-lang/rust

Fix ICE when using asm! on an unsupported architecture

Fixes #75220

+29 -3

0 comment

5 changed files

pr created time in 5 days

create barnchAmanieu/rust

branch : fix_asm_arch

created branch time in 5 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

Hmm… in GCC and LLVM, i immediate operands can be symbol names which are kept as symbolic in the generated assembly, but it looks like the new asm! doesn't support this. @Amanieu Do you remember if this has been discussed before?

We have a special sym operand type specifically for this.

Also note that it should be possible to add support for both sym and const operands to global_asm! (and in fact I've mentioned this before as an obvious next step for the inline asm project group).

Amanieu

comment created time in 5 days

issue commentrust-lang/rust

Tracking Issue for raw slice getters (slice_ptr_get)

I don't particularly care for the name bikeshed but I agree that this method would be useful.

RalfJung

comment created time in 5 days

pull request commentrust-lang/rust

Stabilize deque_make_contiguous

ping for checkboxes @SimonSapin @withoutboats @sfackler

jonhoo

comment created time in 5 days

pull request commentrust-lang/rust

[android] Add support for android's file descriptor ownership tagging to libstd.

@rfcbot fcp merge

jmgao

comment created time in 5 days

pull request commentrust-lang/rfcs

RFC: Teach `concat!()` to join `[u8]` and byte `str`

I'm happy to start an FCP on behalf of the libs team once the RFC text is updated to use concat_bytes!.

estebank

comment created time in 5 days

pull request commentrust-lang/rust

Upgrade to LLVM 11 (rc1)

@cuviper In both cases lb <symbol> and mv are pseudo-instructions that expand to those code sequences. The only difference is that LLVM's disassembly output seems to have changed. I guess we just have to fix the tests to accept both the new and old formats...

cuviper

comment created time in 6 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

Regarding your other question about writing to struct fields, this can be done using const operands and the offset_of! macro (make sure you enable the unstable_const feature).

Amanieu

comment created time in 6 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

As @bjorn3 said, your code is incorrect and does not do what you think it does. The RFC clearly states that:

Any registers not specified as inputs will contain an undefined value on entry to the asm block.

This means that your asm! is simply writing undefined values to your struct. The fact that these undefined values happen to be the input values of your function is a coincidence: the compiler is free to place any value it wants in those registers prior to executing the asm!.

If you are writing a function with a custom calling convention then the whole function must be written in assembly. This can be done either through global_asm! or a #[naked] function.

Amanieu

comment created time in 6 days

push eventAmanieu/atomic-rs

Adam Reichold

commit sha 0932d0fd57e3ea0f0d7d18389129dbad77407816

Make fallback implementation optional to increase confidence in performance characteristics.

view details

Amanieu d'Antras

commit sha 33100c999dedb8fbfbec21ce5a0bca71d731b112

Merge pull request #17 from adamreichold/make-fallback-optional Make fallback implementation optional to increase confidence in performance characteristics.

view details

push time in 6 days

PR merged Amanieu/atomic-rs

Make fallback implementation optional to increase confidence in performance characteristics.

Still a draft as it depends on #15 but wanted to post it to facilitate discussions. Still a draft as it depends on #18

+10 -0

0 comment

3 changed files

adamreichold

pr closed time in 6 days

pull request commentGilnaa/memoffset

Add container_of

I am actively using this macro in intrusive-collections. I will continue maintaining my implementation there, but I feel it would be better to have a properly reviewed implementation in memoffset.

My thought was that we could modify raw_field to use offset_of internally with code like this:

(&parent as *const _ as *const u8).add(offset_of!($ParentType, $field)) as *const $FieldType

This should create a pointer with the proper provenance which can be used with container_of.

Amanieu

comment created time in 6 days

pull request commentrust-lang/rust

Limit I/O vector count on Unix

@bors rollup=iffy

adamreichold

comment created time in 6 days

pull request commentrust-lang/rust

Limit I/O vector count on Unix

@bors r+

adamreichold

comment created time in 6 days

pull request commentrust-lang/rust

Limit I/O vector count on Unix

Sounds good!

adamreichold

comment created time in 6 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

I don't understand what you are trying to do. handler is extern "C" and therefore uses the SysV ABI which requires r12-r15 to be preserved since they are modified by the asm code.

Amanieu

comment created time in 6 days

Pull request review commentAmanieu/atomic-rs

Make fallback implementation optional to increase confidence in performance characteristics.

 macro_rules! match_atomic {                  $impl             }+            #[cfg(feature = "fallback")]             _ => $fallback_impl,+            #[cfg(not(feature = "fallback"))]+            _ => unimplemented!(),

I would prefer a panic! with a clear message explaining that the fallback feature is disabled.

adamreichold

comment created time in 6 days

PR opened nix-rust/nix

Expose SeekData and SeedHole on all Linux targets

These were previously missing on musl and mips targets because of missing definitions in the libc crate.

+17 -10

0 comment

1 changed file

pr created time in 6 days

create barnchAmanieu/nix

branch : musl_seek

created branch time in 6 days

fork Amanieu/nix

Rust friendly bindings to *nix APIs

fork in 6 days

pull request commentrust-lang/rust

Limit I/O vector count on Unix

@bors r+

adamreichold

comment created time in 6 days

PR merged Amanieu/atomic-rs

Upgrade to Rust edition 2018

Still a draft as it depends on #15

+5 -6

2 comments

4 changed files

adamreichold

pr closed time in 6 days

push eventAmanieu/atomic-rs

Adam Reichold

commit sha 35579fc88bfc34438054b646ee81695ccc61dc69

Upgrade to Rust edition 2018.

view details

Amanieu d'Antras

commit sha 34f48f5be15abcecfd14fad5312bb16b89d7954c

Merge pull request #18 from adamreichold/upgrade-to-edition-2018 Upgrade to Rust edition 2018

view details

push time in 6 days

issue commentrust-lang/wg-allocators

Introduce a byte-type

I don't think this is worth the added complexity of another type. We use u8 everywhere else for this in the standard library (e.g. I/O buffers) and it has worked just fine so far.

TimDiekmann

comment created time in 6 days

Pull request review commentrust-lang/rust

Limit I/O vector count on Unix

 impl Drop for FileDesc {         let _ = unsafe { libc::close(self.fd) };     } }++#[cfg(test)]+mod tests {+    use super::{FileDesc, IoSlice};++    #[test]+    fn limit_vector_count() {+        let stdout = FileDesc { fd: 0 };

Standard output is fd 1. 0 is standard input.

adamreichold

comment created time in 6 days

pull request commentAmanieu/atomic-rs

Replace use of unstable features by use of autocfg

Thanks for your work on this!

I'll merge the other PRs once you rebase them and mark them as ready for review.

adamreichold

comment created time in 6 days

push eventAmanieu/atomic-rs

Adam Reichold

commit sha df02842847bad2cd50ef43c47ab7e9cbdb6f6b85

Replace use of unstable features by use of autocfg Instead of using unstable features, this detects the availability of the various atomic types using the autocfg crate by dynamically compiling code snippets via the build script. This still raises the MSRV however as const functions Atomic::new and Atomic::is_lock_free cannot be defined below Rust 1.31.0.

view details

Adam Reichold

commit sha ceba87603f43965d52f3011898d02363482970ce

Bump MSRV to 1.45.0 and therefore remove the has_fetch_min configuration flag.

view details

Adam Reichold

commit sha 833996f2b9c31a2f3851f8ad0f497a0f76bbc2fe

Remove fallback to word-sized atomics as we explicitly detect the available atomics now.

view details

Adam Reichold

commit sha 756aa4624bcecf2f0149119a991045545713cbbb

Add detection and usage of 128 bit atomic integers.

view details

Amanieu d'Antras

commit sha b9020a51a46572602297f0893da011803f5dca21

Merge pull request #15 from adamreichold/drop-nightly-bump-msrv

view details

push time in 6 days

PR merged Amanieu/atomic-rs

Replace use of unstable features by use of autocfg

Instead of using unstable features, this detects the availability of the various atomic types using the autocfg crate by dynamically compiling code snippets via the build script.

This still raises the MSRV however as const functions Atomic::new and Atomic::is_lock_free cannot be defined below Rust 1.31.0.

Fixes #14

+219 -670

0 comment

6 changed files

adamreichold

pr closed time in 6 days

issue closedAmanieu/atomic-rs

Please consider detecting compiler version or bumping minimum supported Rust version

A lot of the compiler features behind this crate's nightly feature have reached stable Rust but cannot be used when targeting it as feature flags are not allowed by the stable compiler. It would be nice if the compiler version could be detected automatically using crates like rustc_version or autocfg so that the nightly becomes unnecessary and the relevant functionality like smaller-than-word-size atomics become available on stable Rust. (Alternatively, the minimum supported Rust version could be increased to avoid the complexity of feature detection at the cost of dropping support for older compiler versions.)

closed time in 6 days

adamreichold
more