We were using them for every expansion, instead of using `Name`.
Also converted `CompilerExpansion` into an enum so its nicer to use and takes up less space.
Will profile later, but this should be a small improvement in memory usage.
r? @eddyb
* Suppresses warnings that main is unused when testing (#12327)
* Makes `--test` work with explicit `#[start]` (#11766)
* Fixes some cases where the normal main would not be disabled by `--test`, resulting in compilation failures.
Some hoedown FFI changes:
- `HOEDOWN_EXT_NO_INTRA_EMPHASIS` constant changed.
- Updated/tidied up all callback function signatures.
- All opaque data access has an additional layer of indirection for some reason (`hoedown_renderer_data`).
This also fixes#27862.
This handles the case where the #[main] function is buried deeper in
the ast than we search for #[test] functions. I'm not sure why one
would want to do that, but since it works in standard compilation it
should also work for tests.
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.
