The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
Tracking issue: #31756
RFC: rust-lang/rfcs#1467
I've made these unstable for now. Should they be stabilized straight away since we've had plenty of experience with people using the unstable intrinsics?
This warning was introduced on Nov 28, 2015 and got into 1.6 stable, it was later requalified from a hardwired warning to a warn-by-default lint.
If this patch is landed soon enough, then `match_of_unit_variant_via_paren_dotdot` will get into 1.8 stable as a deny-by-default lint.
My intention is to turn it into a hard error after March 3, 2016, then it will hit stable at 1.9.
r? @nikomatsakis
cc @pnkfelix
Now that #31461 is merged, a failing resolution can never become indeterminate or succeed, so we no longer have to keep trying to resolve failing import directives.
r? @nrc
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
In #31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed#31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!
I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
It's unclear to me whether this test failing under valgrind is actually legit.
The test only fails in valgrind when everything is dynamically linked, and it
appears to work when statically linked.
For now just add the `// no-prefer-dynamic` directive and let's just chalk it up
to a weird valgrind issue.
Closes#31328
It's unclear to me whether this test failing under valgrind is actually legit.
The test only fails in valgrind when everything is dynamically linked, and it
appears to work when statically linked.
For now just add the `// no-prefer-dynamic` directive and let's just chalk it up
to a weird valgrind issue.
Closes#31328
fmt: Make sure write_fmt's implementation can use write_char
It looks like the Adapter inside write_fmt was never updated to forward
the write_char method.
In #31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed#31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!
I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
Remove alternate stack with sigaltstack before unmaping it.
Also reuse existing signal stack if already set, this is especially
useful when working with sanitizers that configure alternate stack
themselves.
This change depends on SS_DISABLE recently introduced in libc crate and updates
this git submodule accordingly.
