trans: don't declare symbols that were already imported.
Fixes#32740 by checking for a declaration before attempting a new one.
Before, `LLVMGetOrInsertFunction` was called for a existing import, but with a different type.
The returned value was a cast function pointer instead of a declaration, and we gave this
value to `llvm::SetFunctionCallConv` & friends , which triggered an LLVM assertion.
Where T is a type that can be compared for equality bytewise, we can use
memcmp. We can also use memcmp for PartialOrd, Ord for [u8] and by
extension &str.
This is an improvement for example for the comparison [u8] == [u8] that
used to emit a loop that compared the slices byte by byte.
One worry here could be that this introduces function calls to memcmp
in contexts where it should really inline the comparison or even
optimize it out, but llvm takes care of recognizing memcmp specifically.
Fix "consider removing this semicolon" help
Check last statement in a block, not the first.
Example of current weirdness: http://is.gd/w80J9h
The help was only rarely emitted, and if so, often incorrectly (see above playpen). It was basically only useful with single-statement functions.
rustdoc: make rustdoc less pass-aware
Instead of hardcoding knowledge about the strip-private pass into the
rendering process we represent (some) stripped items as `ItemEnum::StrippedItem`.
Rustdoc will, for example, generate redirect pages for public items
contained in private modules which have been re-exported to somewhere
externally reachable - this will now not only work for the `strip-private`
pass, but for other passes as well, such as the `strip-hidden` pass.
r? @alexcrichton
Plumb obligations through librustc/infer
Like #32542, but more like #31867.
TODO before merge: make an issue for the propagation of obligations through... uh, everywhere... then replace the `#????`s with the actual issue number.
cc @jroesch
r? @nikomatsakis
Fix issue: Global paths in `use` directives can begin with `super` or `self` #32225
This PR fixes#32225 by warning on `use ::super::...` and `use ::self::...` on `resolve`.
Current changes is the most minimal and ad-hoc.
Remove implicit binder from `FnSpace` in `VecPerParamSpace` (fixes#20526)
This removes the implicit binder from `FnSpace` in `VecPerParamSpace` so that `Binder<T>` is the only region binder (as described in issue #20526), and refactors away `enter_region_binder` and `exit_region_binder` from `TypeFolder`.
resolve: Improve import failure detection and lay groundwork for RFC 1422
This PR improves import failure detection and lays some groundwork for RFC 1422.
More specifically, it
- Avoids recomputing the resolution of an import directive's module path.
- Refactors code in `resolve_imports` that does not scale to the arbitrarily many levels of visibility that will be required by RFC 1422.
- Replaces `ModuleS`'s fields `public_glob_count`, `private_glob_count`, and `resolved_globs` with a list of glob import directives `globs`.
- Replaces `NameResolution`'s fields `pub_outstanding_references` and `outstanding_references` with a field `single_imports` of a newly defined type `SingleImports`.
- Improves import failure detection by detecting cycles that include single imports (currently, only cycles of globs are detected). This fixes#32119.
r? @nikomatsakis
Before this patch, our rust_eh_personality_catch routine would cut
backtracing short at the __rust_try function, due to it not handling
the _US_FORCE_UNWIND bit properly, which is passed by libunwind
implementations on ARM EHABI.
Examples of where the _US_FORCE_UNWIND bit is passed to the PR:
- GCC's libunwind: f1717362de/libgcc/unwind-arm-common.inc (L590)
- LLVM's libunwind: 61278584b5/src/UnwindLevel1-gcc-ext.c (L153)
Only allow using the atomic intrinsics on integer types
Using these with non-integer types results in LLVM asserts. Atomic operations on non-integer types will require values be transmuted into an integer type of suitable size.
This doesn't affect the standard library since `AtomicBool` and `AtomicPtr` currently use `usize` for atomic operations.
r? @eddyb
We need to supply sext/zext attributes to LLVM to ensure that arguments
are extended to the appropriate width in the correct way.
Most platforms extend integers less than 32 bits, though not all.
Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!
At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.
This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.
This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.
Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
When deciding on a coinductive match, we were examining the new
obligation and the backtrace, but not the *current* obligation that goes
in between the two. Refactoring the code to just have the cycle given
as input also made things a lot simpler.
check constants even if they are not used in the current crate
For now this is just a `warn`-by-default lint. I suggest to make it a `deny`-by-default lint in the next release cycle (so no dependencies break), and then in another release cycle move to an error.
cc #19265
cc #3170
