profile
viewpoint
Josh Stone cuviper Red Hat Portland, OR https://blog.cuviper.com AKA jistone

bluss/indexmap 560

A hash table with consistent order and fast iteration; access items by key or sequence index

bluss/either 163

The enum Either with variants Left and Right is a general purpose sum type with two cases.

agrover/froyo 59

A flexible and redundant long-term storage system for Linux, using DM and XFS

cuviper/alloc_geiger 27

A Rust allocator which makes sound when active, like a Geiger counter.

cuviper/autocfg 27

Automatic cfg for Rust compiler features

cuviper/android_device_htc_inc 2

WIP repo for CM Inc. Beware, this is where I break stuff...

cuviper/addr2line 0

A cross-platform `addr2line` clone written in Rust, using `gimli`

cuviper/alga 0

Abstract algebra for Rust.

cuviper/alphanumeric-sort 0

This crate can help you sort order for files and folders whose names contain numerals.

issue commentprabirshrestha/vim-lsp

Should markdown render inside preview on hover?

FWIW, with the builtin markdown syntax, you can at least enable syntax highlighting on code snippets like so:

let g:markdown_fenced_languages = ['go', 'rust']

There's also g:markdown_syntax_conceal=1, but I can't see any effect from setting that, even with g:lsp_hover_conceal=1.

jbizzle

comment created time in 2 days

issue commentrust-num/num-traits

Would removing (or moving) Num::from_str_radix() be ever considered?

why would int implementations panic and not return Err instead?

We're just forwarding to the inherent methods from the standard library. We could pre-check the radix for an error ourselves, but that still has to fit into a ParseIntError. There's also no direct way to construct that type, so we'd have to fake-parse some other string to get the error we want.

Also (just thinking aloud), if returning an unconditional Err is now completely valid, why wouldn't it be a default implementation with some default assoc type as well?

That would be nice, but that feature is still incomplete and unstable: https://github.com/rust-lang/rust/issues/29661

aldanor

comment created time in 4 days

issue commentrust-num/num-traits

Would removing (or moving) Num::from_str_radix() be ever considered?

If FromStrRadix was dropped from standard library, why can't it be dropped from here as well?

That's the messy history of the num crate -- these methods were still #[unstable] in std, so they were deprecated in 1.4 and removed in 1.7. But when copied to num, we don't have such stability mechanisms, so they became de-facto stabilized with everything else here.

I don't intend to make breaking changes to num-traits, since the traits have a lot of cross-crate API interaction for our users. I'm thinking I might finally raise to 1.0 with a compatible semver trick to make that position clear.

On Num::from_str_radix in particular, I think we could relax the radix requirements. It's barely specified now, "Convert from a string and radix <= 36," but the integer implementations also enforce the lower bound, assert!(radix >= 2 && radix <= 36), so they panic otherwise. I suggest we codify that, but also allow that implementations may just return Err for any other unsupported radix. Thus a new type could choose to only support radix = 10 like a normal parse, or they might even return an unconditional Err.

aldanor

comment created time in 4 days

pull request commentrust-lang/rust

llvm: backport SystemZ fix for AGR clobbers

r? @nikic

cuviper

comment created time in 4 days

PR opened rust-lang/rust

llvm: backport SystemZ fix for AGR clobbers

Fixes #77382.

+1 -1

0 comment

1 changed file

pr created time in 4 days

create barnchcuviper/rust

branch : systemz-agr-clobbers-cc

created branch time in 4 days

push eventrust-lang/llvm-project

Josh Stone

commit sha 77a0125981b293260c9aec6355dff46ec707ab59

[SystemZ] Use LA instead of AGR in eliminateFrameIndex(). (#80) Since AGR clobbers CC it should not be used here. Fixes https://bugs.llvm.org/show_bug.cgi?id=47736. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D89034 (cherry picked from commit d851495f2fe614c4c860bda1bd3c80bfbe48360b) Co-authored-by: Jonas Paulsson <paulsson@linux.vnet.ibm.com>

view details

push time in 4 days

PR merged rust-lang/llvm-project

[SystemZ] Use LA instead of AGR in eliminateFrameIndex().

This is a backport for rust-lang/rust#77382.

+17 -17

0 comment

3 changed files

cuviper

pr closed time in 4 days

push eventcuviper/autohash

Matt Brubeck

commit sha 871b6f64fede7df2ccbca9dfe187da9d71f9d65c

Update version in README

view details

Amanieu d'Antras

commit sha 81173a8ad00a4418d9ea2b1fc406bd9953d726d8

Merge pull request #199 from mbrubeck/docs Update version in README

view details

Josh Stone

commit sha 4c9355b062105ad84e7393db3d969d8e9d2b6329

Initial release, forked from `hashbrown` 0.9.0 Everything should be functional, but the documentation and tests still need to be converted to `AutoHashMap` and `AutoHashSet`. That's not a simple rename since the requirements on the key types are different.

view details

Josh Stone

commit sha fd27d5b4c279969fc2412e9ceb2ebe24003787f1

Remove from_key_hashed_nocheck's Q: Hash We don't need `Q: Hash` in `RawEntryBuilder::from_key_hashed_nocheck`, because a hash value is already provided. This makes it consistent with the same method on `RawEntryBuilderMut` that already lacked `Q: Hash`.

view details

bors

commit sha 0f386166035412b11e4f82263a750d9a6e0fd97a

Auto merge of #200 - cuviper:from_key_hashed_nocheck, r=Amanieu Remove from_key_hashed_nocheck's Q: Hash We don't need `Q: Hash` in `RawEntryBuilder::from_key_hashed_nocheck`, because a hash value is already provided. This makes it consistent with the same method on `RawEntryBuilderMut` that already lacked `Q: Hash`.

view details

Josh Stone

commit sha e793bd2dd1ba3287295812885fb2b374a84ee860

Make `RawTable::drain` safe The documentation indicated a safety question of the lifetime, but there is a lifetime parameter on `RawDrain` to ensure that. Also, the similar `par_drain` is already a safe method.

view details

Josh Stone

commit sha a56db6974e64405b5f38e2ef27f608c27cb98bd4

Adjust the safety comments on drain/into_iter_from The safety contract for these methods is really about the validity of the given `RawIter` for this `RawTable`. Once that's established, the lifetime is no longer a concern, since `RawDrain<'_, T>` has a borrow and `RawIntoIter<T>` is a consuming owner.

view details

Josh Stone

commit sha 20cdb93a347c893b2c941b1da82b1f6ef7820f9e

Add more safe methods to RawTable These methods combine lookup and bucket operations so the caller doesn't have to deal with unsafe bucket methods. - `get`: `find` and `as_ref` - `get_mut`: `find` and `as_mut` - `insert_entry`: `insert` and `as_mut` - `remove_entry`: `find` and `remove` - `erase_entry`: `find` and `erase`

view details

bors

commit sha d26b37ae3ae2baf05f5a421abb6616bed0424bf5

Auto merge of #201 - cuviper:safe-drain, r=Amanieu Make `RawTable::drain` safe The documentation indicated a safety question of the lifetime, but there is a lifetime parameter on `RawDrain` to ensure that. Also, the similar `par_drain` is already a safe method. I also adjusted the safety comments on `drain_iter_from`/`into_iter_from`. The safety contract for these methods is really about the validity of the given `RawIter` for this `RawTable`. Once that's established, the lifetime is no longer a concern, since `RawDrain<'_, T>` has a borrow and `RawIntoIter<T>` is a consuming owner.

view details

Muhammad Mominul Huque

commit sha 35f7b47c0a75d72a90b657844eec2b2712426495

Add MSRV in the README.md This adds an MSRV badge in the `README.md` similar to the [`regex` project](https://github.com/rust-lang/regex/blob/master/README.md). I got the MSRV from the `CHANGELOG.md`

view details

Amanieu d'Antras

commit sha 298f675147b90dfda842c964755ad5b97622be23

Merge pull request #203 from mominul/patch-1 Add MSRV in the README.md

view details

Amanieu d'Antras

commit sha d2b5aec2f11d7d5301685a4a141ae6e6bb2b9342

Merge pull request #202 from cuviper/safer-raw-access Add more safe methods to RawTable

view details

Amanieu d'Antras

commit sha 34c11891e13fa3c0d08b0540e869aace9d347c26

Version 0.9.1

view details

Markus Westerlind

commit sha b7830cf7b065b41af54fb97f8a72081ac98219b9

fix: Only instantiate RawTable's reserve functions once ...per key-value. Each of the previous closures would cause an entirely new reserve/resize function to be instantiated. By using this trick (which std uses for iterator adaptors), we always get a single instantiatiation per key (modulo the insert_with_hasher method).

view details

Markus Westerlind

commit sha 63832ed4e38ac29c24d6396d91076b0ebf55f8d5

Don't instantiate get functions twice either

view details

Markus Westerlind

commit sha d8463d03efd0fc2b8ccb0b5db135cc7f5b5cd3f7

Address review comments

view details

Markus Westerlind

commit sha 5e11d32570c1e0f708864a0285527dfb5f0ada44

nits

view details

bors

commit sha adf06c2e7f3371ffdbff04388d3894978fdf2bf4

Auto merge of #204 - Marwes:less_ir, r=Amanieu fix: Only instantiate RawTable's reserve functions once ...per key-value. Each of the previous closures would cause an entirely new reserve/resize function to be instantiated. By using this trick (which std uses for iterator adaptors), we always get a single instantiatiation per key (modulo the insert_with_hasher method).

view details

Markus Westerlind

commit sha 297917de4b5cfe5e2d5961637bf59f68a06f756c

Include dropping behaviour in bench

view details

Markus Westerlind

commit sha 58314211634dc0ef2369b3dac40cc6d9a225a6ea

perf: Remove the need for unwrap when using ProbeSeq

view details

push time in 4 days

PR opened rust-lang/llvm-project

[SystemZ] Use LA instead of AGR in eliminateFrameIndex().

This is a backport for rust-lang/rust#77382.

+17 -17

0 comment

3 changed files

pr created time in 4 days

create barnchcuviper/llvm-project

branch : systemz-agr-clobbers-cc

created branch time in 4 days

pull request commentrust-lang/rust

Use probe-stack=inline-asm in LLVM 11+

The specific failures start here. I'm not sure why this change would cause new stack overflows, but it needs investigation.

failures:

---- [ui] ui/unsized-locals/by-value-trait-object-safety-rpass.rs stdout ----

error: test run failed!
status: signal: 6
command: "/checkout/obj/build/i686-unknown-linux-gnu/test/ui/unsized-locals/by-value-trait-object-safety-rpass/a"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

------------------------------------------


---- [ui] ui/unsized-locals/by-value-trait-object-safety-withdefault.rs stdout ----

error: test run failed!
status: signal: 6
command: "/checkout/obj/build/i686-unknown-linux-gnu/test/ui/unsized-locals/by-value-trait-object-safety-withdefault/a"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

------------------------------------------


---- [ui] ui/unsized-locals/autoderef.rs stdout ----

error: test run failed!
status: signal: 6
command: "/checkout/obj/build/i686-unknown-linux-gnu/test/ui/unsized-locals/autoderef/a"
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

------------------------------------------



failures:
    [ui] ui/unsized-locals/autoderef.rs
    [ui] ui/unsized-locals/by-value-trait-object-safety-rpass.rs
    [ui] ui/unsized-locals/by-value-trait-object-safety-withdefault.rs

test result: FAILED. 10827 passed; 3 failed; 109 ignored; 0 measured; 0 filtered out
erikdesjardins

comment created time in 4 days

pull request commentrust-lang/rust

Use probe-stack=inline-asm in LLVM 11+

Thanks! This may have perf implications, so I'm excluding it from rollups.

@bors r+ rollup=never

erikdesjardins

comment created time in 5 days

issue commentrust-lang/rust

coreos-installer test segfaults on s390x-unknown-linux-gnu

I'll backport that patch after the LLVM 11.0.0 final rebase lands -- #77948. (I thought about doing that together, but figured it would be better to separate concerns.)

cuviper

comment created time in 5 days

PR opened rust-lang/rust

Rebase LLVM onto 11.0.0 final
+2 -2

0 comment

2 changed files

pr created time in 5 days

create barnchcuviper/rust

branch : rust-llvm11

created branch time in 5 days

create barnchrust-lang/llvm-project

branch : rustc/11.0-2020-10-12

created branch time in 5 days

pull request commentrust-num/num-traits

Add a blanket impl<T: ToPrimitive> ToPrimitive for &T

Hmm, I doubt we could change NumCast::from without it being a breaking change. I guess we could add a new method like from_ref, but that would need T: Clone so it can be defaulted to use from, while all of our impls can call specific to_foo conversions without cloning.

Personally, I avoid NumCast because I don't like how it overlaps with From::from. Directly using ToPrimitive is also better for &BigInt since the methods only require &self.

I'd also suggest the standard TryFrom if possible, stable as of Rust 1.34, but that's not implemented for floating point.

coolreader18

comment created time in 5 days

issue commentcuviper/autocfg

Probing for nightly

I'm open to it. We could add some nightly detection in the version part of the API (and dev is the equivalent), but I would also want to see some principled feature probing. There could be methods to set global #![feature(...)], like what I'm doing for no_std in #27, and then folks can use probes to see whether a feature works as they expect. Maybe the feature flags should be set on a per-probe basis, but I don't want to double the entire API, so this needs consideration.

The argument against such an api is that it could be too magic and it could be bad for crater i.e. did nightly break the code or was the code always broken with the nightly feature enabled.

I think there are other version-detection build crates that already deal with nightly, so that cat is out of the bag...

But I do agree that this should be used carefully, if at all.

maxbla

comment created time in 5 days

pull request commentrayon-rs/rayon

Update crossbeam dependencies (requires Rust 1.36)

Why do you think bors is confused? It looks like it's just waiting for the review comment. There have sometimes been glitches with bors when updating GitHub Actions config, but that's after approval.

Anyway, this looks good, so let's try it!

bors r+

mbrubeck

comment created time in 5 days

issue openedrust-lang/rust

RangeInclusive::contains doesn't consider exhaustion

I tried this code:

fn main() {
    let mut range = 0..=0;
    assert!(!range.is_empty());
    assert!(range.contains(&0));

    range.next();
    assert!(range.is_empty());
    assert!(!range.contains(&0));
}

I expected to see this happen: all assertions pass.

Instead, this happened: the last assertion fails.

Meta

Playground link

The behavior is the same across stable 1.47.0, 1.48.0-beta.2, and 1.49.0-nightly (2020-10-13 adef9da30f1ecbfeb813).

Analysis

The implementation of is_empty includes a check for the exhausted flag:

    pub fn is_empty(&self) -> bool {
        self.exhausted || !(self.start <= self.end)
    }

But contains only looks at the raw bounds:

    pub fn contains<U>(&self, item: &U) -> bool
    where
        Idx: PartialOrd<U>,
        U: ?Sized + PartialOrd<Idx>,
    {
        <Self as RangeBounds<Idx>>::contains(self, item)
    }

It would be easy to insert !self.exhausted && ... in there, as long as we're OK with the behavior change, which I consider a bug fix. I think the exhausted state of start/end is unspecified, so nobody should be depending on contains working then.

created time in 5 days

issue commentrust-num/num

Rounding error with `f64::from_str_radix`

Well, 2.89 is not a number that can be precisely represented in binary floating point. If you force it to print more digits like `"{:.30?}", you'll get:

Ok(2.890000000000000124344978758018)
Ok(2.889999999999999680255768907955)

We can also print to_bits():

0100000000000111000111101011100001010001111010111000010100011111
0100000000000111000111101011100001010001111010111000010100011110

So parse did indeed choose a closer approximation, and yes this look like a rounding error.

We could special case radix=10 to use parse, but it would be nicer to improve this for all bases.

TatriX

comment created time in 5 days

issue closedrust-lang/rust

1.19 powerpc64le run-pass test failures: simd-intrinsic-generic-cast

On Debian:

------stderr------------------------------
thread 'main' panicked at 'f64 -> i32 (i32x4(-1234567, 12345678, -123456792, 1234567936) != i32x4(-1234567, 12345678, -123456789, 1234567890))', /<<BUILDDIR>>/rustc-1.19.0+dfsg3/src/test/run-pass/simd-intrinsic-generic-cast.rs:127
note: Run with `RUST_BACKTRACE=1` for a backtrace.

------------------------------------------

Not sure if this is related to #42778

closed time in 6 days

infinity0

issue commentrust-lang/rust

1.19 powerpc64le run-pass test failures: simd-intrinsic-generic-cast

Yeah, we should be good here.

infinity0

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentrust-lang/rust

Use probe-stack=inline-asm in LLVM 11+

+// min-llvm-version: 11.0+// revisions: x86_64 i686+// assembly-output: emit-asm+//[x86_64] compile-flags: --target x86_64-unknown-linux-gnu+//[i686] compile-flags: --target i686-unknown-linux-gnu+// compile-flags: -C llvm-args=--x86-asm-syntax=intel++#![feature(no_core, lang_items)]+#![crate_type = "lib"]+#![no_core]++#[lang = "sized"]+trait Sized {}+#[lang = "copy"]+trait Copy {}++// Check that inline-asm stack probes are generated correctly.+// When stack usage is relatively small, the probing loop will be unrolled.++// CHECK-LABEL: small_stack_probe:+#[no_mangle]+pub fn small_stack_probe(a: [u8; 8192], f: fn([u8; 8192])) {+    // x86_64: sub rsp, 4096+    // x86_64-NEXT: mov qword ptr [rsp], 0+    // x86_64-NEXT: sub rsp, 4096+    // x86_64-NEXT: mov qword ptr [rsp], 0+    // i686: sub esp, 4096+    // i686-NEXT: mov dword ptr [esp], 0+    // i686-NEXT: sub esp, 4096+    // i686-NEXT: mov dword ptr [esp], 0+    let a = a;+    f(a);+}

It may be better to create the array directly in this stack frame -- e.g. take a single u8 as input and create the array from that.

As for the assembly, I don't think we should try to match the exact output. We could CHECK-NOT against the __rust_probestack symbol, and/or loosely CHECK for the page size step 4096, and that's probably good enough to assume some kind of probing is there.

erikdesjardins

comment created time in 6 days

pull request commentrust-num/num-traits

Add a blanket impl<T: ToPrimitive> ToPrimitive for &T

Yes, it is a breaking change, because &T is a fundamental type.

Can you explain why you want to be generic in this way? Maybe it can be done another way, like T: Borrow<U>, U: ToPrimitive to accept either owned or borrowed values.

coolreader18

comment created time in 7 days

issue commentrust-lang/rust

`miri` no longer builds after rust-lang/rust#77731

cc @Aaron1011, I saw you also mentioned that PR in https://github.com/rust-lang/miri/issues/1578.

rust-highfive

comment created time in 9 days

issue commentrust-lang/rust

Build failing after update to Rust 1.47.0

This is probably due to #73084, which AIUI is considered a necessary bug fix even though some code is no longer accepted.

Tamschi

comment created time in 9 days

PR opened rust-lang/rust

doc: disambiguate stat in MetadataExt::as_raw_stat

A few architectures in os::linux::raw import libc::stat, rather than defining that type directly. However, that also imports the function called stat, which makes this doc link ambiguous:

error: `crate::os::linux::raw::stat` is both a struct and a function
  --> library/std/src/os/linux/fs.rs:21:19
   |
21 |     /// [`stat`]: crate::os::linux::raw::stat
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous link
   |
   = note: `-D broken-intra-doc-links` implied by `-D warnings`
help: to link to the struct, prefix with the item type
   |
21 |     /// [`stat`]: struct@crate::os::linux::raw::stat
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to link to the function, add parentheses
   |
21 |     /// [`stat`]: crate::os::linux::raw::stat()
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We want the struct, so it's now prefixed accordingly.

+1 -1

0 comment

1 changed file

pr created time in 10 days

create barnchcuviper/rust

branch : doc-stat

created branch time in 10 days

delete branch cuviper/rust

delete branch : direntry-diet

delete time in 10 days

issue commentrust-lang/rust

Code bloat from monomorphization of methods applied to arrays

This is one of these cases where you'd probably want a #[inline(never)] at the call site in core::array::<impl core::fmt::Debug for [T; N]>::fmt if that were possible.

We could insert a shim #[inline(never)] function to call the slice Debug::fmt.

For other traits, I'd worry about hurting bounds-checking and vectorization if we add artificial barriers.

glandium

comment created time in 10 days

issue closedrust-lang/rust

Rust 1.47.0 snapshot binaries not working with pypa/manylinux1

I have a CI automatic deployment that builds wheels for a Python package built with Rust. Everything used to work fine until the 1.47.0 stable. Now I can't get rust installed on the pypa/manylinux1 docker image which is based on CentOS5 (cf https://github.com/pypa/manylinux)

Here is the output while trying to install rust:

info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: latest update on 2020-10-08, rust version 1.47.0 (18bf6b4f0 2020-10-07)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
info: downloading component 'rust-std'
info: downloading component 'rustc'
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: Defaulting to 500.0 MiB unpack ram
info: installing component 'clippy'
info: installing component 'rust-docs'
info: installing component 'rust-std'
info: installing component 'rustc'
info: installing component 'rustfmt'
/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc: error while loading shared libraries: /root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-ff4ec557f69b94a7.so: ELF file OS ABI invalid

Related to #1345

closed time in 10 days

n1t0

issue commentrust-lang/rust

Rust 1.47.0 snapshot binaries not working with pypa/manylinux1

OK, great, hope that goes well for you!

n1t0

comment created time in 10 days

issue commentrayon-rs/rayon

[docs] rayon-core module

@iRaiko sure, documentation is a great place to contribute, especially from someone with less familiarity with the code.

I don't think rayon-core really needs to say too much itself, because we mostly steer users toward the same interfaces re-exported in the rayon crate. Still, we can definitely do better than "Under construction". :construction:

nikomatsakis

comment created time in 10 days

issue openedrust-lang/rust

Inconsistently documented constraints for IntoIterator::Item

The documentation for IntoIterator is inconsistent in how it shows the Item constraints.

The actual trait declaration looks like this:

pub trait IntoIterator {
    type Item;
    type IntoIter: Iterator<Item = Self::Item>;
    fn into_iter(self) -> Self::IntoIter;
}

The nightly core documentation matches this declaration as of 1.49.0-nightly (3525087ad 2020-10-08). This is good.

However, the nightly std documentation shows no Item constraints at all:

pub trait IntoIterator {
    type Item;
    type IntoIter: Iterator;
    fn into_iter(self) -> Self::IntoIter;
}

The std documentation for 1.48.0-beta.2 is even weirder, using an equality constraint that's not supported (#20041), and this goes all the way back to 1.0.0.

pub trait IntoIterator
where
    <Self::IntoIter as Iterator>::Item == Self::Item,
{
    type Item;
    type IntoIter: Iterator;
    fn into_iter(self) -> Self::IntoIter;
}

created time in 10 days

issue commentrust-num/num-bigint

Algorithm improvements for very large numbers

It would be great to improve the scalability, as long as it's done in a way that doesn't hurt the performance of relatively-small numbers. For example, the current multiplication scales from basic long multiplication to Karatsuba to Toom-3, since constant factors can overwhelm Big-O algorithm scaling. Of course, there may well be possible improvements in small numbers too!

Refactoring the modules is also fine, but please try to do it in incremental steps for ease of review. If you give me a huge PR at once, I'll be less able to deal with it in a timely manner.

tczajka

comment created time in 10 days

issue commentrust-lang/rust

Rust 1.47.0 snapshot binaries not working with pypa/manylinux1

Yes, this is expected. It looks like manylinux acknowledges the support state too:

PEP 513 defined manylinux1_x86_64 and manylinux1_i686 platform tags and the wheels were built on Centos5. Centos5 reached End of Life (EOL) on March 31st, 2017 and thus PEP 571 was proposed.

... where PEP 571 defines manylinux2010 based on CentOS 6. Even that will be done with maintenance support soon (November 30), but I expect to keep Rust support for a while yet.

n1t0

comment created time in 10 days

push eventcuviper/rust

Josh Stone

commit sha 1d06b07765e1be71f3aeec1d0c0f365b0907c7a8

simplify the cfg in ReadDir construction Co-authored-by: David Tolnay <dtolnay@gmail.com>

view details

push time in 10 days

pull request commentrust-lang/rust

add system-llvm-libunwind config option

cc @cuviper

For my part, we don't even have llvm-libunwind packages.

Keruspe

comment created time in 10 days

pull request commentrust-lang/rust

unix/vxworks: make DirEntry slightly smaller

Well that's annoying -- that end_of_stream has always been unused in practice on some targets, but the derive(Clone) that I removed was counting as a use. I've added more conditionals, but I'll pause for re-review just in case.

cuviper

comment created time in 10 days

push eventcuviper/rust

Hanif Bin Ariffin

commit sha dc655b28424549a4775bc2e8c9021d44482bccb1

Prevent stackoverflow

view details

Stein Somers

commit sha 3b051d0171b4e15aff4d2ecacf7659f7278e8e09

BTreeMap: comment why drain_filter's size_hint is somewhat pessimistictid

view details

Dylan MacKenzie

commit sha 29e5e6e766a6aab504b01697f8670f72ec10e8ad

Use MIR dump interface for dataflow

view details

Dylan MacKenzie

commit sha 3b873987381cd8236b6f6e8129ad5c3570cbae68

Print to `stderr` when a graphviz file can't be written `warn` prints nothing by default

view details

Dylan MacKenzie

commit sha e1d76818b2b505e88bcd0c965da945e7e2e4329e

Add `#![feature(const_fn_impl)]`

view details

Dylan MacKenzie

commit sha c959eefa74858785b1d06e6a62c51a905aa75ca7

Add requisite feature gates in the standard library

view details

Dylan MacKenzie

commit sha 7a0c66bad10a7a97111d2438f29be418c16e0a73

Use new feature gate in `impl-trait` tests

view details

Dylan MacKenzie

commit sha 2e412fc8e4165eb88aa552ff43d1e91968455ad2

Bless test outupt

view details

Dylan MacKenzie

commit sha af03b1143ede7bcb3f579fa3cf3ea3e579e2c2fc

Make `min_const_fn` `impl Trait` test into a gate test

view details

Dylan MacKenzie

commit sha c4ef5fdf8f79af3354df5a43c43501b1f03997d5

Remove `fn` from feature name

view details

Dylan MacKenzie

commit sha 9beb6f81e4112eccf9965d46421a1da351b0593a

Make `impl Trait` unstable in all contexts

view details

Dylan MacKenzie

commit sha b5693a39d9d7d1b5404c188899bf7d983c79dfe3

Update error code page

view details

Joshua Nelson

commit sha 2a41342e9ceabc72ec591a64fefb165729b5fbdc

Make src/bootstrap/CHANGELOG.md more helpful

view details

Guillaume Gomez

commit sha 0e45ad890dc1dcbc1d19ce0647e5f3d07284e7b2

Fix tooltip text display

view details

Steve Manuel

commit sha 56b51a9751600dd65ad4bbda5c0f3d7b8c6db970

(docs): make mutex error comment consistent with codebase

view details

bors

commit sha 4437b4b1509c3c15b41a05489c4bddd2fe30e33f

Auto merge of #77464 - ecstatic-morse:const-fn-impl-trait, r=oli-obk Give `impl Trait` in a `const fn` its own feature gate ...previously it was gated under `#![feature(const_fn)]`. I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer. cc #77463 r? `@oli-obk`

view details

Simon Vandel Sillesen

commit sha e231c47aa608b15aa427bc7a8859d87a022c1cfd

perf: UninhabitedEnumBranching void n^2 Avoid n² complexity. This showed up in a profile for match-stress-enum that has 8192 variants

view details

Esteban Küber

commit sha e5f83bcd04e85b8ae5f04d2d95dd9af774d422e2

Detect blocks that could be struct expr bodies This approach lives exclusively in the parser, so struct expr bodies that are syntactically correct on their own but are otherwise incorrect will still emit confusing errors, like in the following case: ```rust fn foo() -> Foo { bar: Vec::new() } ``` ``` error[E0425]: cannot find value `bar` in this scope --> src/file.rs:5:5 | 5 | bar: Vec::new() | ^^^ expecting a type here because of type ascription error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> src/file.rs:5:15 | 5 | bar: Vec::new() | ^^^^^ only `Fn` traits may use parentheses error[E0107]: wrong number of type arguments: expected 1, found 0 --> src/file.rs:5:10 | 5 | bar: Vec::new() | ^^^^^^^^^^ expected 1 type argument ``` If that field had a trailing comma, that would be a parse error and it would trigger the new, more targetted, error: ``` error: struct literal body without path --> file.rs:4:17 | 4 | fn foo() -> Foo { | _________________^ 5 | | bar: Vec::new(), 6 | | } | |_^ | help: you might have forgotten to add the struct literal inside the block | 4 | fn foo() -> Foo { Path { 5 | bar: Vec::new(), 6 | } } | ``` Partially address last part of #34255.

view details

Kazantcev Andrey

commit sha 141544a903d4eb049d0611cbe6c7d248d3f5d425

Remove unnecessary lamda on emitter map.

view details

bors

commit sha 91a79fb29ac78d057d04dbe86be13d5dcc64309a

Auto merge of #76985 - hbina:clone_check, r=estebank Prevent stack overflow in deeply nested types. Related issue #75577 (?) Unfortunately, I am unable to test whether this actually solves the problem because apparently, 12GB RAM + 2GB swap is not enough to compile the (admittedly toy) source file.

view details

push time in 10 days

PR opened rust-lang/rust

Update the backtrace crate to fix big-endian ELF

Pulls in rust-lang/backtrace-rs#373. Fixes #77410.

r? @alexcrichton

+2 -2

0 comment

2 changed files

pr created time in 11 days

create barnchcuviper/rust

branch : big-endian-backtrace

created branch time in 11 days

pull request commentrust-lang/rust

Fix error checking in posix_spawn implementation of Command

Looks nice, thanks!

@bors r+

tmiasko

comment created time in 11 days

pull request commentrust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

I think that's true for PE but not for ELF.

Hmm, then should we make this import part of the platform-specific cfg_if?

cuviper

comment created time in 11 days

pull request commentrust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

Thanks! You've confirmed locally this fixes the issue too?

On s390x, yes.

I actually thought that ELF was always little-endian for common platforms, regardless of the endianness of the platform itself, but this would make sense why things are broken on big-endian!

AFAIK it's always native in ELF, and from a quick skim of glibc it looks like the loader asserts that they match: https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=0c8fa72c4d1d2396f956ce3eb64c02b425b6fd22;hb=HEAD#l1713

Any recollection why that powerpc64 CI has the qemu-ppc64 line commented out?

cuviper

comment created time in 11 days

pull request commentrust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

Oh: https://github.com/rust-lang/backtrace-rs/blob/2b51e00670927b58255f92f2281367187a49f370/ci/docker/powerpc64-unknown-linux-gnu/Dockerfile#L13-L15

cuviper

comment created time in 11 days

pull request commentrust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

I do see big-endian powerpc64 in CI, so I'm not sure how this has been passing -- does it really run the tests?

  • before: https://github.com/rust-lang/backtrace-rs/runs/1183751745?check_suite_focus=true#step:6:897
  • now: https://github.com/rust-lang/backtrace-rs/pull/373/checks?check_run_id=1228634621#step:6:978

I used native s390x to confirm the problem and this fix.

cuviper

comment created time in 11 days

PR opened rust-lang/backtrace-rs

use NativeEndian in symbolize::gimli::Context

Object uses NativeEndian, so the Context should too.

Cc: https://github.com/rust-lang/rust/issues/77410

+1 -1

0 comment

1 changed file

pr created time in 11 days

create barnchcuviper/backtrace-rs

branch : native-endian

created branch time in 11 days

issue commentrust-lang/rust

regression 1.46 -> 1.47 big-endian backtrace-related UI tests failing

Well, this will do it: https://github.com/rust-lang/backtrace-rs/blob/2b51e00670927b58255f92f2281367187a49f370/src/symbolize/gimli.rs#L8

use self::gimli::LittleEndian as Endian;

I think this should this be NativeEndian, unless there's support for backtracing other processes.

infinity0

comment created time in 11 days

issue commentrust-lang/rust

regression 1.46 -> 1.47 big-endian backtrace-related UI tests failing

Mac may have a very different issue, since it's apparently a big-endian thing here. (Plus I don't have a mac at all. :wink: )

infinity0

comment created time in 11 days

Pull request review commentrust-lang/rust

Fix error checking in posix_spawn implementation of Command

 impl Command {         }          unsafe {-            let mut file_actions = PosixSpawnFileActions(MaybeUninit::uninit());-            let mut attrs = PosixSpawnattr(MaybeUninit::uninit());--            libc::posix_spawnattr_init(attrs.0.as_mut_ptr());-            libc::posix_spawn_file_actions_init(file_actions.0.as_mut_ptr());+            let mut attrs = MaybeUninit::uninit();+            let attrs = match libc::posix_spawnattr_init(attrs.as_mut_ptr()) {+                0 => PosixSpawnattr(&mut attrs),+                e => return Err(io::Error::from_raw_os_error(e)),+            };++            let mut file_actions = MaybeUninit::uninit();+            let file_actions = match libc::posix_spawn_file_actions_init(file_actions.as_mut_ptr())+            {+                0 => PosixSpawnFileActions(&mut file_actions),+                e => return Err(io::Error::from_raw_os_error(e)),+            };              if let Some(fd) = stdio.stdin.fd() {-                cvt(libc::posix_spawn_file_actions_adddup2(+                match libc::posix_spawn_file_actions_adddup2(

Yikes, good thing these calls practically never fail, since cvt only checks -1 to use errno, and these return non-zero error numbers directly. But instead of expanding that match everywhere, how about adding a new cvt-like helper method? Something like fn cvt_nz(c_int) -> io::Result<()>.

tmiasko

comment created time in 11 days

PullRequestReviewEvent

issue commentrust-lang/rust

regression 1.46 -> 1.47 big-endian backtrace-related UI tests failing

I have an s390x machine at hand, so I tried a few things. Plain cargo test passes for gimli, addr2line, and object, but backtrace fails two tests:

     Running target/debug/deps/accuracy-18628a8819e01c2c

running 1 test
test doit ... FAILED

failures:

---- doit stdout ----
-----------------------------------
looking for:
        tests/accuracy/main.rs:40
        crates/dylib-dep/src/lib.rs:11
        tests/accuracy/main.rs:39
found:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: start_thread
  17: <unknown>

thread 'doit' panicked at 'failed to find tests/accuracy/main.rs:40', tests/accuracy/main.rs:104:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
     Running target/debug/deps/smoke-9c443e6c4ee6f0fc

running 3 tests
test smoke_test_frames ... FAILED
test sp_smoke_test ... ok
test many_threads ... test many_threads has been running for over 60 seconds
test many_threads ... ok

failures:

---- smoke_test_frames stdout ----
thread 'smoke_test_frames' panicked at 'assertion failed: !can_resolve', tests/smoke.rs:180:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

There are also warnings about FFI safety, but I don't know if they're relevant.

warning: `extern` fn uses type `(&str, u32)`, which is not FFI-safe
  --> crates/dylib-dep/src/lib.rs:10:30
   |
10 | pub extern "C" fn foo(outer: Pos, inner: fn(Pos, Pos)) {
   |                              ^^^ not FFI-safe
   |
   = note: `#[warn(improper_ctypes_definitions)]` on by default
   = help: consider using a struct instead
   = note: tuples have unspecified layout

warning: `extern` fn uses type `fn((&str, u32), (&str, u32))`, which is not FFI-safe
  --> crates/dylib-dep/src/lib.rs:10:42
   |
10 | pub extern "C" fn foo(outer: Pos, inner: fn(Pos, Pos)) {
   |                                          ^^^^^^^^^^^^ not FFI-safe
   |
   = help: consider using an `extern fn(...) -> ...` function pointer instead
   = note: this function pointer has Rust-specific calling convention

warning: 2 warnings emitted
infinity0

comment created time in 11 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

I expect that libstdc++ and libcxx would still overlap in some symbols, while they of course differ in internal details. It seems bad enough when we're mixing libstdc++ versions, but wholly different libraries are a new ballgame.

danieldeankon

comment created time in 11 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

Also, I believe on Linux currently, libLLVM is statically linked to the (build) system libstdc++. Symbols such as _S_empty_rep_storage and std::__cxx11 don't appear in LLVM's libcxx, but do appear in libLLVM's symbol table.

In CI, it's statically linked to our own build of GCC 5.5 libstdc++, because the system GCC is too old to build LLVM.

But yes, we use libstdc++ and not libcxx, which is the default position for Linux. I think we would have a lot more ABI problems if we had a mix of static libcxx with a user's libstdc++ proc-macro. Similarly, if a user overrode the defaults to instead use libcxx in their proc-macro today, I don't expect it would go well...

danieldeankon

comment created time in 11 days

pull request commentrust-lang/rust

unix/vxworks: make DirEntry slightly smaller

Fixed a clone that I had missed...

@bors r=dtolnay

cuviper

comment created time in 11 days

push eventcuviper/rust

Josh Stone

commit sha 5f762014b8f87f23742ec75ac22f9903b95276bc

unix/vxworks: make DirEntry slightly smaller `DirEntry` contains a `ReadDir` handle, which used to just be a wrapper on `Arc<InnerReadDir>`. Commit af75314ecdbc5 added `end_of_stream: bool` which is not needed by `DirEntry`, but adds 8 bytes after padding. We can let `DirEntry` have an `Arc<InnerReadDir>` directly to avoid that.

view details

push time in 11 days

issue openedrust-lang/rustup

rustup.rs "other installation options" link is broken

https://rustup.rs/ has a link in the footer to https://github.com/rust-lang/rustup/#other-installation-methods, but I think it should now be https://rust-lang.github.io/rustup/installation/other.html.

Sorry if this is the wrong repo, as I don't know where that's actually hosted.

created time in 12 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

Via cargo bisect-rustc, I found that the flip from w to u happened with the dist upgrade in #74163 -- another of mine, yay! But I suppose that makes sense as a possible change given how GCC describes this:

On systems with recent GNU assembler and C library, the C++ compiler uses the "STB_GNU_UNIQUE" binding ...

danieldeankon

comment created time in 12 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

I don't know why this changed between LLVM 10 and LLVM 11, but here you can clearly see the difference:

It's interesting that libLLVM-10-rust-1.46.0-stable.so had weak instead of unique symbols, and I believe you that changing this might avoid the problem, but I don't think this is the whole story. The exact regression in the LLVM 11 upgrade #73526 goes from e482c86b9de32c6392cb83aa97d72e22425163f9 to 7ce71c362be9a89e7897ac066aba6e3e6f747800, which can be inspected similarly:

$ objdump -T e482c86b9de32c6392cb83aa97d72e22425163f9/lib/libLLVM-10-rust-1.47.0-nightly.so | grep _ZNSs4nposE
00000000007b5f58 u    DO .rodata        0000000000000008  LLVM_10     _ZNSs4nposE

$ objdump -T 7ce71c362be9a89e7897ac066aba6e3e6f747800/lib/libLLVM-11-rust-1.47.0-nightly.so | grep _ZNSs4nposE
000000000081bb28 u    DO .rodata        0000000000000008  LLVM_11     _ZNSs4nposE

i.e. both have u = unique for that symbol.

I compared the entire list of symbols in those two files, and apart from obvious LLVM API differences, there are a bunch of new STL symbols now included in the file, including stream stuff that may be relevant to the reproducer. Those are all weak though, and the only additions in unique symbols are mersenne_twister_engine data.

danieldeankon

comment created time in 12 days

push eventcuviper/rust

Eduardo Broto

commit sha 332c2dcb4dfe5151d7c8d44cdf96c4abd06db593

Fix dogfood after MatchTypeOnDiagItem

view details

Eduardo Broto

commit sha c86a7e5f38e54f4404cc71874316eb0b4dba200b

Misc doc updates

view details

Eduardo Broto

commit sha d0b5663d30457d1a9ec4f98eb9baff7123b77172

Fix usage of backquotes in suggestion

view details

bors

commit sha 12ce312bb239aa0a347fd9d03fabb2a9f84bfe10

Auto merge of #6013 - ebroto:diagnostic_item_restriction, r=flip1995 Internal lint: suggest `is_type_diagnostic_item` over `match_type` where applicable changelog: none

view details

Lzu Tao

commit sha 78f9ea543154b6a0d6b5b5a86e92d8cc1938b436

Fix clippy hard-code slice::Iter path

view details

bors

commit sha 9f0f035fe0b800adef73864cdcc1c1b528c80547

Auto merge of #6045 - giraffate:remove_extra_blank_line, r=flip1995 Remove an extra blank line in `shadow_same` It seems to be an extra blank line in doc example. changelog: none <img width="1143" alt="スクリーンショット 2020-09-15 8 50 30" src="https://user-images.githubusercontent.com/17407489/93149409-369df080-f731-11ea-9a39-d8bbc72b61ee.png">

view details

Jubilee Young

commit sha 247b73939a619ea4dcb2affbe1c285d20d93a0b8

Move Wrapping<T> ui tests into library

view details

Jubilee Young

commit sha 797cb9526a627c37b9bb9f6be6d3b54789b67c26

Fix to libstd test

view details

Takayuki Nakata

commit sha 44eb66d947191be51f0a7b7d35c05936a4142a97

Add note to `shadow_unrelated` This lint can be disabled at function level.

view details

Haraman Johal

commit sha 16b6cebaa67655a793d90d296c03e2c5496ec4ce

update lint docs

view details

bors

commit sha 190c6ea3690a20024ebc80eefbf91dba0e7fda5f

Auto merge of #6049 - flip1995:rustup, r=flip1995 Fix clippy hard-code slice::Iter path r? `@ghost` changelog: none

view details

bors

commit sha 0695f219945e22d092aa1351a5862abcb4e1f3c3

Auto merge of #6043 - HaramanJohal:margin_of_error, r=matthiaskrgr clarify margin of error in wording of float comparison operator lint messages fixes #6040 changelog: change wording of float comparison operator to make margin of error less ambiguous

view details

Michael Wright

commit sha 8b04c2d6e87b62b88a488383d84268684148723c

Merge branch 'master' into lint-5734

view details

Michael Wright

commit sha ecbe9ac0e9b68b171e4a48db40e91e2e44370c2a

manual-strip: Add additional test

view details

Michael Wright

commit sha 79a0e5110a0168945d43e334e6dc0d12e0bc1487

manual-strip: Fix formatting

view details

Jubilee Young

commit sha ac96f5b39ca7d9fad8571595c476c2db0bce8438

Test and reject out-of-bounds shuffle vectors

view details

Tim Nielens

commit sha 6ba36bcfd3802d9520d0ac48dabfe6dc06d8dc82

option_if_let_else - distinguish pure from impure else expressions

view details

Tomasz Miąsko

commit sha ff1a9e406bfccefedb6c4f2cabc0c4d59ac947d4

Fix underflow when calculating the number of no-op jumps folded When removing unwinds to no-op blocks and folding jumps to no-op blocks, remove the unwind target first. Otherwise we cannot determine if target has been already folded or not. Previous implementation incorrectly assumed that all resume targets had been folded already, occasionally resulting in an underflow: remove_noop_landing_pads: removed 18446744073709551613 jumps and 3 landing pads

view details

Robin Schoonover

commit sha d0ddbb9d0d0d6b9b6adb51b259819ec270421642

Extend testing of rc_buffer lint

view details

Lzu Tao

commit sha ad6f8c6354f4f1bba8101886646929a4985dec77

bump pulldown-cmark v0.8

view details

push time in 12 days

PR opened rust-lang/rust

unix/vxworks: make DirEntry slightly smaller

DirEntry contains a ReadDir handle, which used to just be a wrapper on Arc<InnerReadDir>. Commit af75314ecdbc5 added end_of_stream: bool which is not needed by DirEntry, but adds 8 bytes after padding. We can let DirEntry have an Arc<InnerReadDir> directly to avoid that.

+7 -9

0 comment

2 changed files

pr created time in 12 days

create barnchcuviper/rust

branch : direntry-diet

created branch time in 12 days

issue commentrust-lang/rust

DirEntry should mention it uses a file descriptor until closed

Every DirEntry from the same read_dir will share that handle (via Arc), so it's not exactly a limit in DirEntry objects. For your example of 1..10000, I would expect exactly 9999 file descriptors kept open, no matter how many entries that finds in the inner loop. That's still probably more than your default resource limit though.

ChrisJefferson

comment created time in 12 days

issue commentrust-lang/rust

macro_rules-wrapped asm! fails on att_syntax

Works for me, thanks!

cuviper

comment created time in 12 days

issue commentrayon-rs/rayon

`spawn` is badly named

Is there a reason you can't or don't want to store an independent thread spawner for your case? It seems out of scope to me to have ThreadPool spawn threads that wouldn't actually participate in the pool.

Timmmm

comment created time in 12 days

issue commentrayon-rs/rayon

`spawn` is badly named

Well, the provided build_scoped is an example that wouldn't be 'static, at least, and this is even used in rustc*.

*(rustc really uses a rustc-rayon fork, not rayon directly)

Timmmm

comment created time in 12 days

issue commentrayon-rs/rayon

`spawn` is badly named

@RReverser I don't think there's a way for us to keep the spawn_handler. That closure is only constrained as FnMut and we only keep it in the builder, but it would need Send + Sync + 'static to be a trait object in the ThreadPool or Registry.

Timmmm

comment created time in 12 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

we could also replace rustllvm with a commit directly to LLVM since we maintain a fork anyway which expands the C ABI for us (I think this is true)?

Sort of, but not really. I guess you can say that rustc_llvm (formerly rustllvm) is that expanded C ABI, because it wraps C++ calls in an extern "C" API for Rust FFI. But this stands alone so it can be used with external LLVM too. The only added APIs within our forked LLVM are MCSubtargetInfo::getCPUTable and getFeatureTable, which are still C++, and neither are essential. It would be leaving external LLVM users (distros) behind if we made rust-forked APIs mandatory within LLVM.

danieldeankon

comment created time in 13 days

create barnchcuviper/num-traits

branch : normalize-comments

created branch time in 13 days

PR opened rust-num/num-traits

Normalize the comment style
+6 -7

0 comment

1 changed file

pr created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

Hmm, but it also requires [llvm] link-shared = true. When I set that false, the reproducer behaves properly.

danieldeankon

comment created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

FWIW, I can also reproduce this with my own local rust/llvm build configured with [llvm] static-libstdcpp = true -- so the versions of the static and dynamic libstdc++ are identical.

danieldeankon

comment created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

I'm not sure, but we may need libstdc++ interop symbols between librustc_driver.so (with crate rustc_llvm's C++ wrappers) and libLLVM.so.

danieldeankon

comment created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

When I step through the reproducer's ostream<< in libstdc++-10.2.1-1.fc32.x86_64, here's where it goes wrong:

src/foo.cpp

  1 #include <string>
  2 #include <sstream>
  3  
  4 extern "C" int custom_to_string(unsigned int id) {
  5         std::stringstream os;
  6         os << id;
  7         return os.str().length();
  8 }

libstdc++-v3/include/bits/ostream.tcc

 60            template<typename _CharT, typename _Traits>
 61              template<typename _ValueT>
 62                basic_ostream<_CharT, _Traits>&
 63                basic_ostream<_CharT, _Traits>::
 64                _M_insert(_ValueT __v)
 65                {
 66                  sentry __cerb(*this);
 67                  if (__cerb)
 68                    {
 69                      ios_base::iostate __err = ios_base::goodbit;
 70                      __try
 71                        {
>72                          const __num_put_type& __np = __check_facet(this->_M_num_put);
 73                          if (__np.put(*this, *this, this->fill(), __v).failed())
 74                            __err |= ios_base::badbit;
 75                        }
 76                      __catch(__cxxabiv1::__forced_unwind&)
 77                        {
 78                          this->_M_setstate(ios_base::badbit);
 79                          __throw_exception_again;
 80                        }
 81                      __catch(...)
 82                        { this->_M_setstate(ios_base::badbit); }
 83                      if (__err)
 84                        this->setstate(__err);
 85                    }
 86                  return *this;
 87                }

At line 72, this->_M_num_put is NULL. Then _check_facet calls __throw_bad_cast(), which is caught and line 78 sets badbit. Back in custom_to_string, I can indeed see that stream state:

(gdb) p os.rdstate()
$15 = std::_S_badbit

That's why the stringstream is empty.

I still don't know why we get that NULL, but there was a tell in what I posted earlier -- just the facet lines...

Before:

binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt5ctypeIcEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEERKT_RKSt6locale' [GLIBCXX_3.4]

After:

binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt5ctypeIcEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]

I guess that may need stepping through the stream constructor, but that's a mess of locale code...

danieldeankon

comment created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

Yeah, that SO situation is not a perfect match.

danieldeankon

comment created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

Jonathan Wakely pointed me to one of his Stack Overflow answers: https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects/49119902#49119902

Where you have problems is if you link together objects compiled with different versions of GCC and you have used unstable features from a new C++ standard before GCC's support for that standard is complete.

But we're using GCC 5.5 and building for C++14, which he tells me should be fine in that regard.

There's another caveat about std::string vs. std::__cxx11::string, but our build of LLVM does appear to be using the new ABI there, and my Fedora 32 system is also using the new ABI when building the reproducer

danieldeankon

comment created time in 13 days

issue commentrust-lang/rust

Cargo freezes at Building stage with version 1.46.0

There is C++ in clickhouse-rs-cityhash-sys, but that's not used in a proc-macro like #76980. https://github.com/suharev7/clickhouse-rs/tree/async-await/clickhouse-rs-cityhash-sys/src/cc

A debugger call stack for the hung process would still be helpful too. You replied before that this freezes in cargo build, not cargo run, but that's fine. If a rustc process is hung, that's where we want a debugger.

But it's not completely stuck, just takes much longer than you expect? That suggests some scalability problem in rustc/llvm.

octave99

comment created time in 13 days

issue commentrust-lang/rust

Cargo freezes at Building stage with version 1.46.0

cargo tree --edges no-dev would help us see everything in use.

octave99

comment created time in 13 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

I tried LD_DEBUG myself on your minimal reproducer, and there are a lot of bindings from /lib64/libstdc++.so.6 to .../lib/libLLVM-1x-rust-1.47.0-nightly.so, which seems bad. I don't see any new bindings that way -- this was also happening before LLVM 11 -- but there's a sequence of internal bindings that seem to show that we're on a different track:

With e482c86b9 (just before LLVM 11 landed): debug.e482c86b9.477027.gz

binding file /lib64/libstdc++.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `strcmp' [GLIBC_2.2.5]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt5ctypeIcEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSo9_M_insertImEERSoT_' [GLIBCXX_3.4.9]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSo6sentryC1ERSo' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNKSt5ctypeIcE13_M_widen_initEv' [GLIBCXX_3.4.11]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `memcmp' [GLIBC_2.2.5]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intImEES3_S3_RSt8ios_basecT_' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEE8_M_pbumpEPcS5_l' [GLIBCXX_3.4.21]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `memcpy' [GLIBC_2.14]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSo6sentryD1Ev' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm' [GLIBCXX_3.4.21]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_baseD2Ev' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_base17_M_call_callbacksENS_5eventE' [GLIBCXX_3.4.6]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_base20_M_dispose_callbacksEv' [GLIBCXX_3.4.6]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt3_V214error_categoryD2Ev' [GLIBCXX_3.4.21]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt14error_categoryD2Ev' [GLIBCXX_3.4.15]

With 7ce71c362 (with LLVM 11): debug.7ce71c362.477169.gz

binding file /lib64/libstdc++.so.6 [0] to /lib64/libc.so.6 [0]: normal symbol `strcmp' [GLIBC_2.2.5]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9use_facetISt5ctypeIcEERKT_RKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt9has_facetISt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEEEbRKSt6locale' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSo9_M_insertImEERSoT_' [GLIBCXX_3.4.9]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSo6sentryC1ERSo' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt16__throw_bad_castv' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_allocate_exception' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_throw' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_get_globals' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `__tls_get_addr' [GLIBC_2.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_init_primary_exception' [CXXABI_1.3.11]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt14get_unexpectedv' [GLIBCXX_3.4.20]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZSt13get_terminatev' [GLIBCXX_3.4.20]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_RaiseException' [GCC_3.0]
binding file /lib64/libgcc_s.so.1 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_Find_FDE' [GCC_3.0]
binding file /lib64/libgcc_s.so.1 [0] to /lib64/libc.so.6 [0]: normal symbol `dl_iterate_phdr' [GLIBC_2.2.5]
binding file /lib64/libgcc_s.so.1 [0] to /lib64/libc.so.6 [0]: normal symbol `strlen' [GLIBC_2.2.5]
binding file /lib64/libgcc_s.so.1 [0] to /lib64/libpthread.so.0 [0]: normal symbol `pthread_once'
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetLanguageSpecificData' [GCC_3.0]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetRegionStart' [GCC_3.0]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetIPInfo' [GCC_4.2.0]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNK10__cxxabiv117__class_type_info11__do_upcastEPKS0_PKvRNS0_15__upcast_resultE' [CXXABI_1.3]
binding file /lib64/libgcc_s.so.1 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_GetCFA' [GCC_3.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_SetGR' [GCC_3.0]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_SetIP' [GCC_3.0]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_begin_catch' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt9basic_iosIcSt11char_traitsIcEE11_M_setstateESt12_Ios_Iostate' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_end_catch' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_get_globals_fast' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libgcc_s.so.1 [0]: normal symbol `_Unwind_DeleteException' [GCC_3.0]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt9exceptionD2Ev' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `__cxa_free_exception' [CXXABI_1.3]
binding file /lib64/libstdc++.so.6 [0] to /home/jistone/.rustup/toolchains/COMMIT/bin/rustc [0]: normal symbol `free' [GLIBC_2.2.5]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSo6sentryD1Ev' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_assignERKS4_' [GLIBCXX_3.4.21]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_baseD2Ev' [GLIBCXX_3.4]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_base17_M_call_callbacksENS_5eventE' [GLIBCXX_3.4.6]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_base20_M_dispose_callbacksEv' [GLIBCXX_3.4.6]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt3_V214error_categoryD2Ev' [GLIBCXX_3.4.21]
binding file /lib64/libstdc++.so.6 [0] to /lib64/libstdc++.so.6 [0]: normal symbol `_ZNSt14error_categoryD2Ev' [GLIBCXX_3.4.15]

I don't know that we should read anything into that difference -- seems like it could be happenstance. In any case, I think we're on very shaky ground loading dynamic C++ proc macros into the rustc process with our static libstdc++.


This also looks a bit related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679

danieldeankon

comment created time in 14 days

issue commentrust-lang/rust

coreos-installer test segfaults on s390x-unknown-linux-gnu

Let's see what LLVM devs say: https://bugs.llvm.org/show_bug.cgi?id=47736

cuviper

comment created time in 14 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

LD_DEBUG=bindings may help confirm whether the proc-macro is binding to symbols from our static libstdc++, and which symbols exactly. We can also compare that with a pre-LLVM11 build to see if this issue already existed, perhaps just with less problematic symbols. See man ld.so for more options -- might want to use a LD_DEBUG_OUTPUT file too.

danieldeankon

comment created time in 14 days

issue commentrust-lang/rust

macro_rules-wrapped asm! fails on att_syntax

It's probably relevant that the actual att_syntax token is passed as an arch-conditional $opt:ident parameter here: https://github.com/cuviper/rust-libprobe/blob/ae1286b26693cc29775d71be40f09245031c8a2e/src/platform/systemtap.rs#L83

cuviper

comment created time in 14 days

issue openedrust-lang/rust

macro_rules-wrapped asm! fails on att_syntax

The probe crate uses asm! with att_syntax, because SDT operands are written in ELF notes, to be read by third-party tools expecting that syntax. Recently this has regressed:

~/rust/probe$ cargo check --examples
    Checking probe v0.2.1 (/home/jistone/rust/probe)
error: expected one of `)`, `att_syntax`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, or `readonly`, found `att_syntax`
 --> examples/loop.rs:4:5
  |
4 |     probe!(foo, begin);
  |     ^^^^^^^^^^^^^^^^^^^ expected one of 8 possible tokens
  |
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: expected one of `)`, `att_syntax`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, or `readonly`, found `att_syntax`
 --> examples/loop.rs:8:9
  |
8 |         probe!(foo, loop, i, total);
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected one of 8 possible tokens
  |
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: expected one of `)`, `att_syntax`, `nomem`, `noreturn`, `nostack`, `preserves_flags`, `pure`, or `readonly`, found `att_syntax`
  --> examples/loop.rs:11:5
   |
11 |     probe!(foo, end);
   |     ^^^^^^^^^^^^^^^^^ expected one of 8 possible tokens
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 3 previous errors

error: could not compile `probe`

To learn more, run the command again with --verbose.

cargo bisect-rustc pointed me to #77275 -- cc @petrochenkov. I see that there were regressions with asm! during that review, but not exactly like what I'm seeing here.

Meta

searched nightlies: from nightly-2020-09-28 to nightly-2020-10-04 regressed nightly: nightly-2020-09-30 searched commits: from https://github.com/rust-lang/rust/commit/fc2daaae610b5515438b551a2f3706196a997f35 to https://github.com/rust-lang/rust/commit/381b445ff5751f9f39ec672b623372dff09c276e regressed commit: https://github.com/rust-lang/rust/commit/26373fb4baa9c5b8a7a1e2821fcfa930a85d327d

<details> <summary>bisected with <a href='https://github.com/rust-lang/cargo-bisect-rustc'>cargo-bisect-rustc</a> v0.5.2</summary>

Host triple: x86_64-unknown-linux-gnu Reproduce with:

cargo bisect-rustc --access github -- check --examples

</details>

created time in 14 days

pull request commentrust-lang/rust

Use `RTLD_DEEPBIND` for loading dylibs/proc-macros

I believe RTLD_DEEPBIND is a GNU extension -- libc only defines it under linux/gnu and uclibc/mips.

jonas-schievink

comment created time in 15 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

Long term, we might be better off loading plugins in a helper process. I think the token stream is already marshalled enough that it could be sent inter-process.

danieldeankon

comment created time in 15 days

issue commentrust-lang/rust

Build hang on Linux with nightly and beta toolchains

I suspect this may be a C++ symbol clash with rustc's static libstdc++, since proc-macro libraries are loaded in the same process.

danieldeankon

comment created time in 15 days

issue commentrust-lang/rust

coreos-installer test segfaults on s390x-unknown-linux-gnu

However, trait object vtables can definitely alias globally.

The actual vtable should be shared read-only, which is fine for LLVM noalias.

cuviper

comment created time in 16 days

issue commentrust-lang/rust

coreos-installer test segfaults on s390x-unknown-linux-gnu

there are additional !noalias annotations in the one with the miscompilation.

Box gets special treatment -- PointerKind::UniqueOwned -- did something about your patch affect that visibility?

I'm guessing, maybe before it was dropped indirectly through &mut (Shared pending #54878), but with the more precise drops it may be dropped by value? (UniqueOwned does get noalias.) Of course the Drop trait uses &mut, but I don't know what it looks like when an implicit MIR drop is expanded.

cuviper

comment created time in 16 days

issue commentrust-num/num-complex

Proposal: bytemuck support

Sounds good, and I think even generic support will be fine -- it's #[repr(C)] with two identical fields, so there's never any padding.

ajtribick

comment created time in 16 days

pull request commentrust-lang/rust

Add `IntoIterator` impl for arrays by value (`for [T; N]`)

The same compiler magic that is required to "hide" keyword (such as try or await) from particular editions, not?

Edition keywords can be resolved when we build the initial syntax tree. The change needed here would reach deeper into the type system and method resolution.

LukasKalbertodt

comment created time in 16 days

issue commentrust-lang/rust

coreos-installer test segfaults on s390x-unknown-linux-gnu

Found the instruction reference...

  • LLILH is Load Logical Immediate (low high)
  • AGR is Add (64), Condition code set

So it seems to be clobbering the CLI condition.

I'm guessing the revised enum drops just exposed an existing codegen bug.

cuviper

comment created time in 17 days

issue commentrust-lang/rust

coreos-installer test segfaults on s390x-unknown-linux-gnu

Here's std::io::error::Repr for reference:

enum Repr {
    Os(i32),
    Simple(ErrorKind),
    Custom(Box<Custom>),
}

From <libcoreinst::source::FileLocation as libcoreinst::source::ImageLocation>::sources:

            Err(err) => {
                eprintln!("Couldn't read signature file: {}", err);
                None
            }

The error we get during the test case is Repr::Os(2), ENOENT, "No such file or directory", which prints fine.

With nightly-2020-07-05, the assembly after printing is:

+3102>       brasl   %r14,0x2aa0034d340 <std::io::stdio::_eprint>
+3108>       cli     504(%r15),2
+3112>       mvghi   704(%r15),0
+3118>       jl      0x2aa000cd5b8 <libcoreinst::download::tests::test_write_image_limit+3480>
+3122>       lg      %r13,512(%r15)
+3128>       lg      %r1,8(%r13)
+3134>       lg      %r2,0(%r13)

I believe that cli 2 is comparing the Repr tag, where only Custom needs dropping. When I step through, that jl branch is taken to skip ahead. Otherwise, you can see that it would load 512(%r15) (offset 8 from before) for the Box into %r13, then proceed to dereference that pointer.

With nightly-2020-07-06, the assembly after printing is:

+4514>       brasl   %r14,0x2aa00349d40 <std::io::stdio::_eprint>
+4520>       cli     552(%r15),2
+4524>       llilh   %r1,16
+4528>       agr     %r1,%r15
+4532>       mvghi   768(%r1),0
+4538>       jl      0x2aa000cc2ce <libcoreinst::download::tests::test_write_image_limit+4718>
+4542>       lg      %r13,560(%r15)
+4548>       lg      %r1,8(%r13)
+4554>       lg      %r2,0(%r13)

Looks similar with cli 2, but I don't really speak SystemZ to guess what llilh and agr are doing. But in the debugger I see that this jl branch is not taken, and then it loads a garbage pointer into %r13 (always seems to be 0x21). The load of 8(%r13) is where we SIGSEGV.

cuviper

comment created time in 17 days

issue commentrust-lang/rust

powerpc64: allow querying ELF ABI version

See also https://github.com/rust-lang/rfcs/pull/2992

q66

comment created time in 17 days

pull request commentrust-lang/rfcs

RFC: Add `target_abi` configuration

I think powerpc64 might want this for ELFv1 vs. ELFv2 -- https://github.com/rust-lang/rust/issues/60617

nvzqz

comment created time in 17 days

pull request commentrust-lang/rust

Split up core/test/iter.rs into multiple files

Do you mind reviewing my fns.txt in case there's any other big changes you want me to make?

This seems to be gone now, 404.

danii

comment created time in 17 days

more