If a new cleanup is added to a cleanup scope, the cached exits for that
scope are cleared, so all previous cleanups have to be translated
again. In the worst case this means that we get N distinct landing pads
where the last one has N cleanups, then N-1 and so on.
As new cleanups are to be executed before older ones, we can instead
cache the number of already translated cleanups in addition to the
block that contains them, and then only translate new ones, if any and
then jump to the cached ones, getting away with linear growth instead.
For the crate in #31381 this reduces the compile time for an optimized
build from >20 minutes (I cancelled the build at that point) to about 11
seconds. Testing a few crates that come with rustc show compile time
improvements somewhere between 1 and 8%. The "big" winner being
rustc_platform_intrinsics which features code similar to that in #31381.
Fixes#31381
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes#21000, #25845, and #25846.
Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138
Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.
There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.
Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409
Thanks!
r? @brson
This is very useful when the RwLock is synchronizing access to a data
structure and you would like to return or store guards which contain
references to data inside the data structure instead of the data structure
itself.
WIP implementation of #31209.
The goal is to insert fake/dummy definitions for names that we failed to import so that later resolver stages won't complain about them.
Something went haywire with github last night and the old PR https://github.com/rust-lang/rust/pull/31230 got closed somehow. This new PR is to replace the old one. This incorporates all of the feedback from the other PR.
@alexcrichton I incorporated the suggestion from @semarie and the result is cleaner and clearer. I think this is ready to go.
This mirrors the behavior of `clang-cl.exe` by adding a `CodeView` global
variable when emitting debug information. This should in turn help stack traces
that are generated when code is compiled with debuginfo enabled.
Closes#28133
This is a behavior that some find confusing, so it deserves its own example.
Fixes#31318
I think this wording might be a bit strange, but I couldn't come up with anything better. Feedback very welcome.
Fixes#31098
AFAICT this is the only place where rustdoc explicitly checks if we are on stable before emitting content, so I can't tell if this is the sane way to handle this, or if anything else should be done to make sure that nobody forgets to remove this check when `const` is stabilized.
Any documentation comments that contain raw-string-looking sequences may pretty-print invalid code when expanding them, as the current logic always uses the `r"literal"` form, without appending any `#`s.
This commit calculates the minimum number of `#`s required to wrap a comment correctly and appends `#`s appropriately.
Fixes#27489.
Currently the `mipsel-unknown-linux-gnu` target doesn't actually set the
`target_arch` value to `mipsel` but it rather uses `mips`. Alternatively the
`powerpc64le` target does indeed set the `target_arch` as `powerpc64le`,
causing a bit of inconsistency between theset two.
As these are just the same instance of one instruction set, let's use
`target_endian` to switch between them and only set the `target_arch` as one
value. This should cut down on the number of `#[cfg]` annotations necessary and
all around be a little more ergonomic.
