profile
viewpoint

nagisa/django-bfm 40

[Not really maintained anymore] BFM is an Apache Licenced server file manager for Django made with ease of use and new web technologies in mind.

lucab/memfd-rs 8

A pure-Rust library to work with Linux memfd

nagisa/e4rat-preload-lite 5

More efficient way to preload e4rat file lists.

nagisa/Feeds 3

Feed Reader for GNOME.

nagisa/gnome-shell-theme-min 3

A GNOME-Shell theme without bells or whistles

cpcloud/tensorflow_proto 2

Rusty protobufs for Tensorflow

nagisa/llvm_build_utils.rs 2

LLVM build utils for cargo build scripts

nagisa/django-localflavor-lt 1

Country-specific Django helpers for Lithuania.

nagisa/kazlauskas.me 1

Hakyll based website of mine

pull request commentrust-lang/rust

Implement -Z function-sections=yes|no

@bors r=nagisa,bjorn3

nox

comment created time in 2 hours

Pull request review commentrust-lang/rust

Implement -Z function-sections=yes|no

 options! {DebuggingOptions, DebuggingSetter, basic_debugging_options,         "force all crates to be `rustc_private` unstable (default: no)"),     fuel: Option<(String, u64)> = (None, parse_optimization_fuel, [TRACKED],         "set the optimization fuel quota for a crate"),+    function_sections: Option<bool> = (None, parse_opt_bool, [TRACKED],+        "whether each function should go in its own .text section"),

.text is not exactly the most portable name (e.g. machO uses __text AFAIR). I suggest dropping the . or perhaps the whole .text.

nox

comment created time in 3 hours

PullRequestReviewEvent

issue commentnagisa/rust_libloading

SetThreadErrorMode not found in WindowsXP

I don't have access to either Windows version so you will need to submit a PR to fix how libloading uses SetThreadErrorMode. It currently checks whether Windows reports the call being unimplemented and then falls back. In retrospective this is linking to the symbol statically, so there needs to be something else (weak linking?) as well.

DominicD

comment created time in 4 hours

pull request commentrust-lang/rust

impl<A, B> IntoIterator for (A, B) as Zip

Yeah, I just wanted to point out a potential difference with how this is approached by other languages, but I'm otherwise hoping to see this change happen regardless.

cuviper

comment created time in 8 hours

pull request commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

@bors r=nagisa,oli-obk

eddyb

comment created time in 10 hours

Pull request review commentrust-lang/rust

Add some regression tests

+// check-pass

check-pass does not run the tests. It doesn't even codegen it, only checks that an equivalent of cargo check succeeds.

Alexendoo

comment created time in 11 hours

PullRequestReviewEvent

pull request commentrust-lang/rust

libc: 0.2.79 -> 0.2.80

@bors r=Mark-Simulacrum

nagisa

comment created time in a day

push eventnagisa/rust

Simonas Kazlauskas

commit sha 00abef10b8e7bd71ca377eafe64fc5893c270bb1

libc: 0.2.79 -> 0.2.80

view details

push time in a day

pull request commentrust-lang/rust

Properly define va_arg and va_list for aarch64-apple-darwin

@bors r+

shepmaster

comment created time in a day

Pull request review commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

 impl<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>> FunctionCx<'a, 'tcx, Bx> {             } else {                 let name = kw::Invalid;                 let decl = &self.mir.local_decls[local];-                let (scope, span) = if full_debug_info {-                    self.debug_loc(decl.source_info)+                let dbg_var = if full_debug_info {+                    self.debug_context.as_ref().map(|debug_context| {+                        // FIXME(eddyb) is this `+ 1` needed at all?+                        let kind = VariableKind::ArgumentVariable(arg_index + 1);++                        let arg_ty = self.monomorphize(&decl.ty);++                        let span = self.adjust_span_for_debugging(decl.source_info.span);

This pattern appears to be repeated multiple times throughout the codebase. It might make sense to just have a method that does these three steps in a single location? Not sure what'd it be named tho… adjusted_span_and_dbg_scope maybe?

eddyb

comment created time in a day

Pull request review commentrust-lang/rust

rustc_mir: track inlined callees in SourceScopeData.

 pub struct PerLocalVarDebugInfo<'tcx, D> { }  #[derive(Clone, Copy, Debug)]-pub struct DebugScope<D> {-    pub scope_metadata: Option<D>,+pub struct DebugScope<S, L> {+    // FIXME(eddyb) this should never be `None`, after initialization.+    pub dbg_scope: Option<S>,++    /// Call site location, if this scope was inlined from another function.+    pub inlined_at: Option<L>,+     // Start and end offsets of the file to which this DIScope belongs.     // These are used to quickly determine whether some span refers to the same file.     pub file_start_pos: BytePos,     pub file_end_pos: BytePos, } -impl<D> DebugScope<D> {-    pub fn is_valid(&self) -> bool {-        self.scope_metadata.is_some()+impl<'tcx, S: Copy, L: Copy> DebugScope<S, L> {+    /// DILocations inherit source file name from the parent DIScope.  Due to macro expansions+    /// it may so happen that the current span belongs to a different file than the DIScope+    /// corresponding to span's containing source scope.  If so, we need to create a DIScope+    /// "extension" into that file.+    pub fn adjust_dbg_scope_for_span<Cx: CodegenMethods<'tcx, DIScope = S, DILocation = L>>(+        &self,+        cx: &Cx,+        span: Span,+    ) -> S {+        // FIXME(eddyb) this should never be `None`.+        let dbg_scope = self.dbg_scope.unwrap();

expect and/or unwrap_or_else(|| bug!(...))?

eddyb

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust

Add some regression tests

@bors r+

Alexendoo

comment created time in a day

Pull request review commentrust-lang/rust

Properly define va_arg and va_list for aarch64-apple-darwin

 impl<'f> VaListImpl<'f> {  #[cfg(all(     any(target_arch = "aarch64", target_arch = "powerpc", target_arch = "x86_64"),-    any(not(target_arch = "aarch64"), not(target_os = "ios")),+    any(not(target_arch = "aarch64"), all(not(target_os = "macos"), not(target_os = "ios"))),

minor nit: this is another instance of all(not(...), not(...))

shepmaster

comment created time in a day

PullRequestReviewEvent

pull request commentrust-lang/rust

Optimise align_offset for stride=1 further

https://github.com/rust-lang/rust/pull/75600 has a prior optimisation of this same function, and it did see comparatively large changes in wall-time, though in that case towards the positive side, but also the way I interpret the results, variance is huge too?

nagisa

comment created time in a day

pull request commentrust-lang/rust

Optimise align_offset for stride=1 further

I don't believe this function is used within rustc enough to cause a 50% wall time regression doing anything, but much like @joshtriplett I wasn't even aware there was such a regression.

(I feel like its somewhat of a presentation problem in perf; I don't typically look at all measurement kinds)

nagisa

comment created time in a day

push eventnagisa/rust

Simonas Kazlauskas

commit sha 0b38c402a780f665e300dc3a0ee5d6edcd2aa322

libc: 0.2.79 -> 0.2.80

view details

push time in a day

Pull request review commentrust-lang/rust

libc: 0.2.79 -> 0.2.80

 dependencies = [  "termcolor", ] -[[package]]-name = "env_logger"-version = "0.8.1"-source = "registry+https://github.com/rust-lang/crates.io-index"-checksum = "54532e3223c5af90a6a757c90b5c5521564b07e5e7a958681bcd2afad421cdcd"-dependencies = [- "atty",- "humantime 2.0.1",- "log",- "regex",- "termcolor",-]-

Ah, I see why, needed to update my submodules before cargo updating.

nagisa

comment created time in a day

PullRequestReviewEvent

Pull request review commentrust-lang/rust

libc: 0.2.79 -> 0.2.80

 dependencies = [  "termcolor", ] -[[package]]-name = "env_logger"-version = "0.8.1"-source = "registry+https://github.com/rust-lang/crates.io-index"-checksum = "54532e3223c5af90a6a757c90b5c5521564b07e5e7a958681bcd2afad421cdcd"-dependencies = [- "atty",- "humantime 2.0.1",- "log",- "regex",- "termcolor",-]-

cargo update -p libc did it.

nagisa

comment created time in a day

PullRequestReviewEvent

pull request commentrust-lang/rust

libc: 0.2.79 -> 0.2.80

cc @JohnTitor

nagisa

comment created time in a day

PR opened rust-lang/rust

libc: 0.2.79 -> 0.2.80

This PR bumps the version of the libc crate from 0.2.79 to 0.2.80 in order to hopefully fix a build failure when building the standard library for the tier 3 x86_64-unknown-dragonfly target.

+3 -16

0 comment

1 changed file

pr created time in a day

create barnchnagisa/rust

branch : nagisa/libc-up

created branch time in a day

pull request commentrust-lang/libc

Allow `deprecated` attribute on `f!` macros to fix dragonfly build

Can I have a release with this included so that I could update libstd's libc dependency?

JohnTitor

comment created time in a day

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 359528c77b1e91f3fd9e6e1ce00bb96edd51f93c

Experiment with version ranges, -Zminimal-versions This commit uses version ranges to accurately specify the minimum version of the dependencies required for this library to work. These version bounds are verified in the CI with `-Zminimal-versions` functionality of cargo which forces cargo to select the earliest versions of libraries possible.

view details

push time in a day

PR opened nagisa/rust_libloading

Experiment with version ranges, -Zminimal-versions

This commit uses version ranges to accurately specify the minimum version of the dependencies required for this library to work. These version bounds are verified in the CI with -Zminimal-versions functionality of cargo which forces cargo to select the earliest versions of libraries possible.

+101 -28

0 comment

5 changed files

pr created time in a day

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 7a8fa6980da492b65b7688eb4b6ed094ad304c6a

Experiment with version ranges, -Zminimal-versions This commit uses version ranges to accurately specify the minimum version of the dependencies required for this library to work. These version bounds are verified in the CI with `-Zminimal-versions` functionality of cargo which forces cargo to select the earliest versions of libraries possible.

view details

push time in a day

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 7fcf98fd30705e6ac49861feeb1e573727cd7328

Experiment with version ranges, -Zminimal-versions

view details

push time in a day

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 56b858a6a98f0bd76dbf6031bc28ebabebdcd693

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 40ca9e03739dd0efd18203bdc94ce3aaff88019e

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha c04ad9f3203913b49f1301f0c913c4c3f502f866

Magic?

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 81b76ba379b361cdb9140c65b42d7ec38ca16c75

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

PullRequestReviewEvent

pull request commentrust-lang/libc

Allow `deprecated` attribute on `f!` macros to fix dragonfly build

I was going to test it but could not because my test involves -Zbuild-std (and I don't have the time to set up anything else); libstd depends on a specific libc crate version I wasn't able to patch out, so I'll just have to trust my gut and say it LGTM.

JohnTitor

comment created time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha c111824b154b7a9d99ebf0a3bbfad86e55cbffe9

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 6c879c93123eabbd4ff9162701bce351469f6556

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha a48ad44356b960d977f083366e19b349d7093ed9

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 58b932c38268ba7c6de888dedee01a46f0a61fd0

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 7c8432742fee122e0c7221a38b1c58733cf2e95b

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

issue openedrust-lang/libc

Fails to build on dragonfly target with a macro matcher failure

error: no rules expected the token `#`
Error:    --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.79/src/unix/bsd/freebsdlike/dragonfly/errno.rs:4:5
    |
4   |     #[deprecated(since = "0.2.77", "Use `__errno_location()` instead")]
    |     ^ no rules expected this token in macro call
    | 
   ::: /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.79/src/macros.rs:230:9
    |
230 |         macro_rules! f {
    |         -------------- when calling this macro

From a brief look at the code it seems like f! has not been written in a way that would make it expect an item with attributes, making building of libc fail when this attribute was added.

created time in 2 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 4bb67dfa504dfad78815d4d4b9d044b4ff0d1ec5

Experiment with version ranges, -Zminimal-versions

view details

push time in 2 days

create barnchnagisa/rust_libloading

branch : nagisa/minimal-versions

created branch time in 2 days

issue commentrust-lang/compiler-team

inherit stable annotations in enum variants and field items

@rfcbot reviewed

I still think libstd is in a position where additional care regarding stability of its APIs warrants the annotation burden, but I don't have much reason to block this.

nikomatsakis

comment created time in 3 days

Pull request review commentrust-lang/rust

Properly define va_arg and va_list for aarch64-apple-darwin

 pub(super) fn emit_va_arg(     // is lacking in some instances, so we should only use it as a fallback.     let target = &bx.cx.tcx.sess.target;     let arch = &bx.cx.tcx.sess.target.arch;-    match (&**arch, target.options.is_like_windows) {+    match (&**arch, target.options.is_like_windows, target.options.is_like_osx) {         // Windows x86-        ("x86", true) => {+        ("x86", true, _) => {             emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(4).unwrap(), false)         }         // Generic x86-        ("x86", _) => {+        ("x86", _, _) => {             emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(4).unwrap(), true)         }         // Windows AArch64-        ("aarch64", true) => {+        ("aarch64", true, _) => {             emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(8).unwrap(), false)         }-        // iOS AArch64-        ("aarch64", _) if target.target_os == "ios" => {+        // macOS/iOS AArch64+        ("aarch64", _, true) => {

Entirely your call, but I believe doing so for all kinds of effective guards will produce nicer code overall.

shepmaster

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Add lint for panic!("{}")

+// build-pass (FIXME(62277): should be check-pass)++const C: &str = "abc {}";+static S: &str = "{bla}";++#[allow(unreachable_code)]+fn main() {

Can you add a test that ensures this lint does not fire on any arbitrary macro that's named panic! (e.g. a custom-defined one)?

m-ou-se

comment created time in 3 days

PullRequestReviewEvent

pull request commentrust-lang/rust

impl<A, B> IntoIterator for (A, B) as Zip

While I'm a fan of this change, I'm worried that there's another interpretation to (a, b).into_iter() – iterate over a and b in turn. This may end up being confusing to some people who are not already aware with how this construct operates in Rust. This is especially relevant because that's the behaviour you get in e.g. Python.

Further consideration may reveal that the interpretation is not actually valid in general, because Rust iterators are not polymorphic like they are in e.g. Python. Nevertheless I think the overlap is big between the people who may initially assume the Python-like behaviour and people who are not likely to come up to a similar conclusion.

cuviper

comment created time in 3 days

pull request commentrust-lang/rust

Bump backtrace-rs to enable Mach-O support on iOS.

@bors r+

cutsoy

comment created time in 3 days

pull request commentrust-lang/rust

Loop instead of recursion

r? @nagisa r=me

Overall LGTM. Left a minor style nit but up to you if you want to address it.

@bors delegate=bugadani

bugadani

comment created time in 3 days

Pull request review commentrust-lang/rust

Loop instead of recursion

 use rustc_span::{source_map::Spanned, Span}; impl<'a, 'hir> LoweringContext<'a, 'hir> {     crate fn lower_pat(&mut self, p: &Pat) -> &'hir hir::Pat<'hir> {         ensure_sufficient_stack(|| {-            let node = match p.kind {-                PatKind::Wild => hir::PatKind::Wild,-                PatKind::Ident(ref binding_mode, ident, ref sub) => {-                    let lower_sub = |this: &mut Self| sub.as_ref().map(|s| this.lower_pat(&*s));-                    let node = self.lower_pat_ident(p, binding_mode, ident, lower_sub);-                    node-                }-                PatKind::Lit(ref e) => hir::PatKind::Lit(self.lower_expr(e)),-                PatKind::TupleStruct(ref path, ref pats) => {-                    let qpath = self.lower_qpath(-                        p.id,-                        &None,-                        path,-                        ParamMode::Optional,-                        ImplTraitContext::disallowed(),-                    );-                    let (pats, ddpos) = self.lower_pat_tuple(pats, "tuple struct");-                    hir::PatKind::TupleStruct(qpath, pats, ddpos)-                }-                PatKind::Or(ref pats) => hir::PatKind::Or(-                    self.arena.alloc_from_iter(pats.iter().map(|x| self.lower_pat(x))),-                ),-                PatKind::Path(ref qself, ref path) => {-                    let qpath = self.lower_qpath(-                        p.id,-                        qself,-                        path,-                        ParamMode::Optional,-                        ImplTraitContext::disallowed(),-                    );-                    hir::PatKind::Path(qpath)-                }-                PatKind::Struct(ref path, ref fields, etc) => {-                    let qpath = self.lower_qpath(-                        p.id,-                        &None,-                        path,-                        ParamMode::Optional,-                        ImplTraitContext::disallowed(),-                    );+            let mut pattern = p;

minor style nit: you can make the argument itself mut instead of introducing a new binding.

bugadani

comment created time in 3 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Add some regression tests

r? @nagisa r=me

I nitted a minor style issue, but otherwise this PR LGTM. Your call if you want to address it or just land as is.

Alexendoo

comment created time in 3 days

Pull request review commentrust-lang/rust

Add some regression tests

+// check-pass++pub trait Trait1 {

Minor nit: This could use some (re-)formatting.

Alexendoo

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Support custom allocators in `Box`

 impl<T> Box<T> {     pub fn pin(x: T) -> Pin<Box<T>> {         (box x).into()     }+}++impl<T, A: AllocRef> Box<T, A> {+    /// Allocates memory in the given allocator then places `x` into it.+    ///+    /// This doesn't actually allocate if `T` is zero-sized.+    ///+    /// # Examples+    ///+    /// ```+    /// #![feature(allocator_api)]+    ///+    /// use std::alloc::System;+    ///+    /// let five = Box::new_in(5, System);+    /// ```+    #[unstable(feature = "allocator_api", issue = "32838")]+    #[inline]+    pub fn new_in(x: T, alloc: A) -> Self {+        let mut boxed = Self::new_uninit_in(alloc);+        unsafe {+            boxed.as_mut_ptr().write(x);+            boxed.assume_init()+        }+    }++    /// Constructs a new box with uninitialized contents in the provided allocator.+    ///+    /// # Examples+    ///+    /// ```+    /// #![feature(allocator_api, new_uninit)]+    ///+    /// use std::alloc::System;+    ///+    /// let mut five = Box::<u32, _>::new_uninit_in(System);+    ///+    /// let five = unsafe {+    ///     // Deferred initialization:+    ///     five.as_mut_ptr().write(5);+    ///+    ///     five.assume_init()+    /// };+    ///+    /// assert_eq!(*five, 5)+    /// ```+    #[unstable(feature = "allocator_api", issue = "32838")]+    // #[unstable(feature = "new_uninit", issue = "63291")]

Hm, I wonder if that should really be documented as a feature request to enable cfg-ish syntax to allow saying something like unstable(all(...)) or unstable(any(...)).

TimDiekmann

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Support custom allocators in `Box`

 impl<T> Box<T> {     pub fn pin(x: T) -> Pin<Box<T>> {         (box x).into()     }+}++impl<T, A: AllocRef> Box<T, A> {+    /// Allocates memory in the given allocator then places `x` into it.+    ///+    /// This doesn't actually allocate if `T` is zero-sized.+    ///+    /// # Examples+    ///+    /// ```+    /// #![feature(allocator_api)]+    ///+    /// use std::alloc::System;+    ///+    /// let five = Box::new_in(5, System);+    /// ```+    #[unstable(feature = "allocator_api", issue = "32838")]+    #[inline]+    pub fn new_in(x: T, alloc: A) -> Self {+        let mut boxed = Self::new_uninit_in(alloc);+        unsafe {+            boxed.as_mut_ptr().write(x);+            boxed.assume_init()+        }+    }++    /// Constructs a new box with uninitialized contents in the provided allocator.+    ///+    /// # Examples+    ///+    /// ```+    /// #![feature(allocator_api, new_uninit)]+    ///+    /// use std::alloc::System;+    ///+    /// let mut five = Box::<u32, _>::new_uninit_in(System);+    ///+    /// let five = unsafe {+    ///     // Deferred initialization:+    ///     five.as_mut_ptr().write(5);+    ///+    ///     five.assume_init()+    /// };+    ///+    /// assert_eq!(*five, 5)+    /// ```+    #[unstable(feature = "allocator_api", issue = "32838")]+    // #[unstable(feature = "new_uninit", issue = "63291")]

Commented code should be removed before landing.

TimDiekmann

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Properly define va_arg and va_list for aarch64-apple-darwin

 pub struct VaList<'a, 'f: 'a> {      #[cfg(all(         any(target_arch = "aarch64", target_arch = "powerpc", target_arch = "x86_64"),-        any(not(target_arch = "aarch64"), not(target_os = "ios")),+        any(not(target_arch = "aarch64"), all(not(target_os = "macos"), not(target_os = "ios"))),

Minor style nit not(any(...)) instead of all(not(...), not(...))?

shepmaster

comment created time in 3 days

PullRequestReviewEvent

pull request commentrust-lang/rust

Properly define va_arg and va_list for aarch64-apple-darwin

r=me, your call if you want to do anything about the style comment.

shepmaster

comment created time in 3 days

Pull request review commentrust-lang/rust

Properly define va_arg and va_list for aarch64-apple-darwin

 pub(super) fn emit_va_arg(     // is lacking in some instances, so we should only use it as a fallback.     let target = &bx.cx.tcx.sess.target;     let arch = &bx.cx.tcx.sess.target.arch;-    match (&**arch, target.options.is_like_windows) {+    match (&**arch, target.options.is_like_windows, target.options.is_like_osx) {         // Windows x86-        ("x86", true) => {+        ("x86", true, _) => {             emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(4).unwrap(), false)         }         // Generic x86-        ("x86", _) => {+        ("x86", _, _) => {             emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(4).unwrap(), true)         }         // Windows AArch64-        ("aarch64", true) => {+        ("aarch64", true, _) => {             emit_ptr_va_arg(bx, addr, target_ty, false, Align::from_bytes(8).unwrap(), false)         }-        // iOS AArch64-        ("aarch64", _) if target.target_os == "ios" => {+        // macOS/iOS AArch64+        ("aarch64", _, true) => {

Minor style nit: matching on forever increasing tuple elements seems untenable in the future. It seems to me like if target.options.is_like_osx would result in slightly more maintainable code.

shepmaster

comment created time in 3 days

PullRequestReviewEvent

issue closedrust-fuzz/arbitrary

Issue re-strutcturing Vec<u8> from a libfuzz test

I've got a simple fuzz test

fuzz_target!(|data: Vec<u8>| {
    if data.len() > 1 {
        panic!("asfa");
    }
});

launching with cargo fuzz and libfuzzer I've got

SUMMARY: libFuzzer: deadly signal
...
Base64: BB8fHx8qKv//
...

fuzz/artifacts/test/crash-327090b23ecd21b1ed2a745974e0df92e975c3ee

Output of `std::fmt::Debug`:

        [
            186,
            186,
            186,
            10,
            186,
            10,
            0,
            0,
         ]

If I want to use this data in a test

use arbitrary::Arbitrary;
        let a = base64::decode("BB8fHx8qKv//").unwrap();
        let mut b = arbitrary::Unstructured::new(&a[..]);
        let c = <Vec<u8>>::arbitrary(&mut b);
        dbg!(c);

I've got

[src/fuzz.rs:90] c = Ok(
    [],
)

same if I use

        let a = include_bytes!("../fuzz/artifacts/test/crash-327090b23ecd21b1ed2a745974e0df92e975c3ee");

This doesn't happen without using Vec

arbitrary version is v0.4.7 on the base project and in the fuzz project

closed time in 3 days

RCasatta

issue commentrust-fuzz/arbitrary

Issue re-strutcturing Vec<u8> from a libfuzz test

You may want to check either the implementation of fuzz_target! and replicate it, or not use fuzz_target! at all, so that it is obvious that the tests you have match your fuzzers.

This is also most plausibly not a arbitrary issue, so I'm going to close it, both the fuzz_target and the base64-encoded data come from libfuzzer (linked above).

RCasatta

comment created time in 3 days

issue closedrust-fuzz/libfuzzer

Publish crate to crates.io

Any blockers?

closed time in 3 days

frewsxcv

issue commentrust-fuzz/libfuzzer

Publish crate to crates.io

I'm pretty sure we're publishing this crate to crates.io, so closing this out.

frewsxcv

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrust-lang/compiler-builtins

Use REP MOVSQ/STOSQ on x86_64

+#![feature(test)]++extern crate test;+use test::{black_box, Bencher};++extern crate compiler_builtins;+use compiler_builtins::mem::{memcmp, memcpy, memmove, memset};++fn memcpy_builtin(b: &mut Bencher, n: usize) {+    let v1 = vec![1u8; n];+    let mut v2 = vec![0u8; n];+    b.iter(|| {

minor nit: set b.bytes = n as u64;?

josephlr

comment created time in 3 days

pull request commentrust-lang/rust

Set .llvmbc and .llvmcmd sections as allocatable

That could be the case, but ultimately I think it is fine to revert this first (if this PR is indeed confirmed to be the issue) and then think about how to introduce it without causing a regression.

glandium

comment created time in 3 days

pull request commentrust-lang/rust

Set .llvmbc and .llvmcmd sections as allocatable

There are a couple situations where bitcode may be embedded:

  1. -Cembed-bitcode is specified;
  2. LTO is enabled;
  3. Target needs bitcode (think iOS).

I suspect that libstd.so is built with LTO enabled, one of the ways bitcode embedding might be enabled through. I'm open to backing this out, but from what I can tell the compiler is not behaving incorrectly.

glandium

comment created time in 3 days

push eventstandard-ai/crate2nix

Simonas Kazlauskas

commit sha 6306d752998e7c8630d66b9e3b13df6dfbd421b6

Do not fail on `cfg(weird)` dependencies

view details

Simonas Kazlauskas

commit sha 2fb5f1fc0ecd953414cf031394f7e7a14f678839

Update Crate.nix files

view details

push time in 3 days

PR merged standard-ai/crate2nix

Do not fail on `cfg(weird)` dependencies

cc https://github.com/kolloch/crate2nix/issues/141

+36 -25

0 comment

6 changed files

nagisa

pr closed time in 3 days

pull request commentkolloch/crate2nix

WIP: add support for cross-compilation

I believe crate2nix is not actively maintained for some time. I just forked this for my own purposes and started addressing problems that matter to me in my fork.

lopsided98

comment created time in 3 days

push eventstandard-ai/crate2nix

Simonas Kazlauskas

commit sha 6bb70a7848ec8c8003dff1bf8e2910edfd18fa5c

Update Crate.nix files

view details

push time in 3 days

push eventstandard-ai/crate2nix

Simonas Kazlauskas

commit sha a25807e6095789ec9fc467bbdc10ede1c09f8112

Do not fail on `cfg(weird)` dependencies

view details

push time in 3 days

push eventstandard-ai/crate2nix

Simonas Kazlauskas

commit sha 3ef9c89330c0c1570071f93552637363051220b7

Do not fail on `cfg(weird)` dependencies

view details

push time in 3 days

PR opened standard-ai/crate2nix

Do not fail on `cfg(weird)` dependencies

cc https://github.com/kolloch/crate2nix/issues/141

+4 -1

0 comment

2 changed files

pr created time in 3 days

create barnchstandard-ai/crate2nix

branch : nagisa/weird-target-cfg-deps

created branch time in 3 days

created tagnagisa/rust_libloading

tag0.6.5

A better library for loading dynamic libraries

created time in 3 days

push eventnagisa/rust_libloading

Simonas Kazlauskas

commit sha 4ad1af8ae9d577562e5dc1280f222713a17e8cf2

Bump to 0.6.5

view details

push time in 3 days

push eventnagisa/rust_libloading

Paolo Barbolini

commit sha 4fd0f25d314387839bd312f8ce0c72cd62fcf20b

Bump cfg-if to 1.0

view details

push time in 3 days

issue commentrust-lang/stacker

Benchmarks / Performance impact?

Nothing published as far as I am aware of. Perhaps the closest real-world example would be from integration of stacker into rustc.

Avi-D-coder

comment created time in 4 days

issue closeddtolnay/trybuild

If tests from multiple test suites are being run in parallel, try build may look at the wrong results

Consider code like this:

// src/tests/a.rs
#[test]
fn a() {
    let t = trybuild::TestCases::new();
    t.compile_fail("a_case.rs");
}

// src/tests/b.rs
#[test]
fn b() {
    let t = trybuild::TestCases::new();
    t.compile_fail("b_case.rs");
}

If these two test suites run in parallel, trybuild will clobber (AFAICT) the same temporary crate directory (in target) and compare outputs from wrong crate build.

cargo itself does not run test suites in parallel, however, so reproducing this may involve running cargo test first, and then running the produced test suites by hand, both at the same time, or perhaps running multiple instances of cargo at once.

My understanding of the root cause may be wrong, but if it is correct, I think it could be trivially fixed by "just" making sure the generated -test crates are unique.

closed time in 5 days

nagisa

issue openeddtolnay/trybuild

If tests from multiple test suites are being run in parallel, try build may look at the wrong results

Consider code like this:

# src/tests/a.rs
#[test]
fn a() {
    let t = trybuild::TestCases::new();
    t.compile_fail("a_case.rs");
}

# src/tests/b.rs
#[test]
fn b() {
    let t = trybuild::TestCases::new();
    t.compile_fail("b_case.rs");
}

If these two test suites run in parallel, trybuild will clobber (AFAICT) the same temporary crate directory (in target) and compare outputs from wrong crate build.

cargo itself does not run test suites in parallel, however, so reproducing this may involve running cargo test first, and then running the produced test suites by hand, both at the same time, or perhaps running multiple instances of cargo at once.

My understanding of the root cause may be wrong, but if it is correct, I think it could be trivially fixed by "just" making sure the generated -test crates are unique.

created time in 5 days

delete branch nagisa/rust_tracy_client

delete branch : master

delete time in 7 days

push eventnagisa/rust_tracy_client

Simonas Kazlauskas

commit sha de16486f08874b18c249af12e86513c05c7f9716

Fix version support table

view details

push time in 7 days

create barnchnagisa/rust_tracy_client

branch : master

created branch time in 7 days

issue commentnagisa/rust_tracy_client

macOS: Segfault just after connecting from Tracy profiler

Please report this against Tracy itself. This kind of issue been seen when the tracy profiler operates without TLS being initialized. We strive to force such initialization for function calls that are wrapped by tracy-client and tracy-client-sys, but in this particular case it seems like this is a thread that's entirely internal to tracy itself, so I cannot really do much about it.

superdump

comment created time in 7 days

push eventlucab/memfd-rs

Maarten de Vries

commit sha 8b77812f889115321405c00f100a20d99b2df575

Implement AsRawFd and IntoRawFd for Memfd.

view details

Maarten de Vries

commit sha 9d670ee5111ebc26046e96b367747e68b7e987af

Add safe constructor from objects owning raw file descriptors.

view details

Maarten de Vries

commit sha 7d4cf31fd3e0432e8c32de839b0376105e329f96

Replace `Either` dependency with `Result`.

view details

push time in 7 days

PR merged lucab/memfd-rs

Reviewers
Implement AsRawFd, IntoRawFd for Memfd and allow safe construction from impl AsRawFd + IntoRawFd.

This PR implements AsRawFd and IntoRawFd for Memfd, and adds Memfd::try_from_fd.

try_from_fd takes an objects that is both AsRawFd and IntoRawFd. It uses AsRawFd to test the file descriptor before calling IntoRawFd. Otherwise, we could not return the original object unharmed.

It also uses Result as return type rather than Either. I think Result properly represents the fact that the conversion failed, and it avoids an external dependency. I was thinking to also replace the return value try_from_file with Result, but that would be a breaking change. Would you be ok with that?

Fixes #11

+48 -13

2 comments

3 changed files

de-vri-es

pr closed time in 7 days

more