Fix (and extend) src/test/run-pass/foreign-call-no-runtime.rs
While going over various problems signaled by valgrind when running `make check` on a build configured with `--enable-valgrind`, I discovered a bug in this test case.
Namely, the test case was previously creating an `i32` (originally an `int` aka `isize` but then we changed the name and the fallback rules), and then reading from a `*const isize`. Valgrind rightly complains about this, since we are reading an 8 byte value on 64-bit systems, but in principle only 4 bytes have been initialized.
(I wish this was the only valgrind unclean test, but unfortunately there are a bunch more. This was just the easiest/first one that I dissected.)
Issue #27583 was caused by the fact that `LUB('a,'b)` yielded `'static`, even if there existed a region `'tcx:'a+'b`. This PR replaces the old very hacky code for computing how free regions relate to one another with something rather more robust. This solves the issue for #27583, though I think that similar bizarro bugs can no doubt arise in other ways -- the root of the problem is that the region-inference code was written in an era when a LUB always existed, but that hasn't held for some time. To *truly* solve this problem, it needs to be generalized to cope with that reality. But let's leave that battle for another day.
r? @aturon
These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:
* The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
* The `core::atomic` module now lives in `core::sync::atomic`. The `core::sync` module is otherwise empty, but ripe for expansion!
* The `core::prelude::v1` module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
* Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the `flt2dec` module is now used for "privacy").
After this commit, the remaining large unstable functionality specific to libcore is:
* `raw`, `intrinsics`, `nonzero`, `array`, `panicking`, `simd` -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
* `num::Float` - this extension trait for floats needs to be audited for functionality (much of that is happening in #27823) and may also want to be renamed to `FloatExt` or `F32Ext`/`F64Ext`.
* Should the extension traits for primitives be stabilized in libcore?
I believe other unstable pieces are not isolated to just libcore but also affect the standard library.
cc #27701
While going over various problems signaled by valgrind when running
`make check` on a build configured with `--enable-valgrind`, I
discovered a bug in this test case.
Namely, the test case was previously creating an `i32` (originally an
`int` aka `isize` but then we changed the name and the fallback
rules), and then reading from a `*const isize`. Valgrind rightly
complains about this, since we are reading an 8 byte value on 64-bit
systems, but in principle only 4 bytes have been initialized.
(I wish this was the only valgrind unclean test, but unfortunately
there are a bunch more. This was just the easiest/first one that I
dissected.)
Currently `f32 % f32` will generate a link error on 32-bit MSVC because LLVM
will lower the operation to a call to the nonexistent function `fmodf`. Work
around in this in the backend by lowering to a call to `fmod` instead with
necessary extension/truncation between floats/doubles.
Closes#27859
Currently `f32 % f32` will generate a link error on 32-bit MSVC because LLVM
will lower the operation to a call to the nonexistent function `fmodf`. Work
around in this in the backend by lowering to a call to `fmod` instead with
necessary extension/truncation between floats/doubles.
Closes#27859
Stop using stability to hide the implementation details of ParseFloatError and
instead move the error type into the `dec2flt` module. Also move the
implementation blocks of `FromStr for f{32,64}` into `dec2flt` directly.
This implements https://github.com/rust-lang/rfcs/pull/1199 (except for doing all the platform intrinsics).
Things remaining for SIMD (not necessarily in this PR):
- [x] I (@huonw) am signed up to ensure the compiler matches the RFC, when it lands
- [x] the platform specific intrinsics aren't properly type checked at the moment (LLVM will throw a "random" assertion)
- [ ] there's a lot of useful intrinsics that are missing, including whole platforms (mips, powerpc)
- [ ] the target-feature `cfg` detection/adding is not so great at the moment
- [x] I think the platform specific intrinsics should go in their own `extern` ABI (i.e. not `"rust-intrinsic"`)
(I'm adjusting the RFC to reflect the latter.)
I think it would be very nice for this to land without requiring the RFC to land first, because of the first point, and because this is the only way for any further work to happen/be experimented with, without requiring people to build/install/multirust a compiler from a custom branch.
r? @alexcrichton
This is theoretically a breaking change, but GitHub search turns up no
uses of it, and most non-built-in cfg's are passed via cargo features,
which look like `feature = "..."`, and hence can't overlap.
Current behaviour demo: http://is.gd/l3FEgo
(The span is printed at the start of the source code)
This patch moves the span to the use of `$i` in the macro rhs (as the code comment already claims)
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes#27389
This PR implements the majority of RFC 1214. In particular, it implements:
- the new outlives relation
- comprehensive WF checking
For the most part, new code receives warnings, not errors, though 3 regressions were found via a crater run.
There are some deviations from RFC 1214. Most notably:
- we still consider implied bounds from fn ret; this intersects other soundness issues that I intend to address in detail in a follow-up RFC. Fixing this without breaking a lot of code probably requires rewriting compare-method somewhat (which is probably a good thing).
- object types do not check trait bounds for fear of encountering `Self`; this was left as an unresolved question in RFC 1214, but ultimately feels inconsistent.
Both of those two issues are highlighted in the tracking issue, https://github.com/rust-lang/rust/issues/27579. #27579 also includes a testing matrix with new tests that I wrote -- these probably duplicate some existing tests, I tried to check but wasn't quite sure what to look for. I tried to be thorough in testing the WF relation, at least, but would welcome suggestions for missing tests.
r? @nrc (or perhaps someone else?)
This commit removes all unstable and deprecated functions in the standard
library. A release was recently cut (1.3) which makes this a good time for some
spring cleaning of the deprecated functions.
