I think you miscalibrated your time machine...

LGTM, thanks!

@bors r+ rollup

I think this will give an unused warning (denied) on some targets. Better to import it at the start of posix_spawn where you know it's used.

This is about RangeInclusive, so your example should be 0..=5, but otherwise yes! Once you advance the iterator, contains(&0) will be false, and this is already the case. Well, except if you advance in reverse to exhaustion, then it would be "empty" but still "contain" start==end==0, until this PR.

The inclusive end is special by nature, that's the whole point. Once the iterator reaches start == end, we have two possible states: !exhausted where the next value is that start/end value, then exhausted where we are empty. But contains didn't consider the latter state, which is what I'm addressing now.

I've moved the exhausted check to RangeBounds::end_bound, per @SkiFire13's observation in https://github.com/rust-lang/rust/issues/77941#issuecomment-712420024.

Digging deeper it looks like the same problem happens when using the range to index after it has been exhausted (which doesn't use contains). Playground link

This would have to be addressed in SliceIndex<str>/SliceIndex<[T]> for RangeInclusive<usize>.

The problem is likely the implementation of RangeBounds<T>::end_bound for both RangeInclusive<T> and RangeInclusive<&T> which marks the end bound as inclusive even if the range has been exhausted.

That's an interesting thought -- maybe it should return an exclusive end when the iterator is exhausted?

I think it's not a breaking change, but I suppose that's debatable. I would not suggest that any existing Num implementations should reduce their radix abilities, or at least that's a breaking change consideration for that type. I think it's OK that new Num implementations may be limited, just as new implementations of Add may have unique overflow limitations, for example.

But my earlier point was that 1.0 would not have any breaking changes either, just reflect the unchanging status quo.

I think it's a good idea to enforce this, but the assertion will not be very meaningful to a user. Your change from result to r will be less meaningful in the panic message, and a user has to be a bit savvy to know that this is a POSIX error number.

Maybe they should use cvt_nz instead? Then we can unwrap it for a formatted error message, either directly here or from the next caller level up.

Hmm, I thought we fixed that cmp direction in D82867, but it's possible we missed a case...

does this PR enable LLVM assertions for all crates or is it limited to CI in some way?

The latter -- this only affects builds used in CI testing, not the dist-* builds that are released to users.

This might want @rust-lang/libs FCP per https://github.com/rust-lang/rust/issues/77941#issuecomment-708610055.

When a range has finished iteration, is_empty returns true, so it should also be the case that contains returns false.

Fixes #77941.

Thanks! I updated the CI lockfile as well to get that passing.

bors r+

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.

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

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.

r? @nikic

Fixes #77382.

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

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

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

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

@bors r+ rollup=never

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.)

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.

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.

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+

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.

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.

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

Yeah, we should be good here.

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.

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.

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

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

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.

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.

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

OK, great, hope that goes well for you!

@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:

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;
}

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.

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.

cc @cuviper

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

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.

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

r? @alexcrichton

Looks nice, thanks!

@bors r+

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?

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?

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

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.

Object uses NativeEndian, so the Context should too.

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

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.

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: )

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<()>.

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

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.

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...

Fixed a clone that I had missed...

@bors r=dtolnay

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.

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 ...

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.

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.

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.

Works for me, thanks!

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.

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)

@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.

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.

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

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.

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.

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...

Yeah, that SO situation is not a perfect match.

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

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.