querify layout and move param env out of the infcx
The main goal of this PR is to move the parameter environment *out* of the inference context. This is because the inference environment will soon be changing over the course of inference --- for example, when we enter into a `for<'a> fn(...)` type, we will push a new environment with an increasing universe index, rather than skolemizing the `'a` references. Similarly, each obligation will soon be able to have a distinct parameter environment, and therefore the `Obligation` struct is extended to carry a `ParamEnv<'tcx>`. (I debated about putting it into the cause; seems plausible, but also weird.)
Along the way, I also reworked how layout works, moving the layout cache into a proper query along the lines of needs-drop and friends.
Finally, tweaks the inference context API. It seemed to be accumulating parameters at an alarming rate. The main way to e.g. make a subtype or equality relationship is to do the following:
infcx.at(cause, param_env).sub(a, b)
infcx.at(cause, param_env).eq(a, b)
In both cases, `a` is considered the "expected" type (this used to be specified by a boolean). I tried hard to preserve the existing notion of what was "expected", although in some cases I'm not convinced it was being set on purpose one way or the other. This is why in some cases you will see me do `sup(b, a)`, which is otherwise equivalent to `sub(a, b)`, but sets the "expected type" differently.
r? @eddyb
cc @arielb1
Support VS 2017
Fixes#38584
This replaces all the MSVC linker logic with that from the 'gcc' crate. The code looks the same, but there could be regressions.
I've only tested this with x86_64.
r? @alexcrichton
cc @vadimcn @retep998
Translate array drop glue using MIR
I was a bit lazy here and used a usize-based index instead of a pointer iteration. Do you think this is important @eddyb?
r? @eddyb
This fixes leakage on panic with arrays & slices. I am using a C-style
for-loop instead of a pointer-based loop because that would be ugly-er
to implement.
Mark various items and fields as private or pub(crate), and remove a function that turns out to be unused.
These are not used anywhere in-tree, but I guess it's a [breaking-change] for plugins.
This support is needed for bindgen to work well on 32-bit Windows, and
also enables people to begin experimenting with C++ FFI support on that
platform.
Fixes#42044.
Use the trait-environment+type as the key. Note that these
are only invoked on types that live for the entire compilation
(no inference artifacts). We no longer need the various special-case
bits and caches that were in place before.
debuginfo: Generate unique DW_AT_names for compilation units to work around OSX linker bug
This should fix issue #39160 and does not seem to cause any problems.
cc @tromey, @Manishearth
r? @jdm
add -Z pre-link-arg{,s} to rustc
This PR adds two unstable flags to `rustc`: `-Z pre-link-arg` and `-Z
pre-link-args`. These are the counterpart of the existing `-C link-arg{,s}`
flags and can be used to pass extra arguments at the *beginning* of the linker
invocation, before the Rust object files are passed.
I have [started] a discussion on the rust-embedded RFCs repo about settling on a
convention for passing extra arguments to the linker and there are two options
on discussion: `.cargo/config`'s `target.$T.rustflags` and custom target
specification files (`{pre,,post}-link-args` fields). However, to compare these
two options on equal footing this `-Z pre-link-arg` feature is required.
[started]: https://github.com/rust-embedded/rfcs/pull/24
Therefore I'm requesting landing this `-Z pre-link-arg` flag as an experimental
feature to evaluate these two options.
cc @brson
r? @alexcrichton
This does not actually improve build times, since it still depends
on rustc_trans, but is better layering and fits the multi-backend
future slightly better.
Consequently, session creation can no longer initialize LLVM.
The few places that use the compiler without going through
rustc_driver/CompilerCalls thus need to be careful to manually
initialize LLVM (via rustc_trans!) immediately after session
creation.
This means librustc is not rebuilt when LLVM changes.
Move the code for loading metadata from rlibs and dylibs from
rustc_metadata into rustc_trans, and introduce a trait to avoid
introducing a direct dependency on rustc_trans.
This means rustc_metadata is no longer rebuilt when LLVM changes.
This commit adds two unstable flags to `rustc`: `-Z pre-link-arg` and `-Z
pre-link-args`. These are the counterpart of the existing `-C link-arg{,s}`
flags and can be used to pass extra arguments at the *beginning* of the linker
invocation, before the Rust object files are passed.
remove the #[inline] attribute from drop_in_place
Apparently LLVM has exponential code growth while inlining landing pads
if that attribute is present.
Fixes#41696.
beta-nominating because regression.
r? @eddyb
rustc: Add a new `-Z force-unstable-if-unmarked` flag
This commit adds a new `-Z` flag to the compiler for use when bootstrapping the
compiler itself. We want to be able to use crates.io crates, but we also want
the usage of such crates to be as ergonomic as possible! To that end compiler
crates are a little tricky in that the crates.io crates are not annotated as
unstable, nor do they expect to pull in unstable dependencies.
To cover all these situations it's intended that the compiler will forever now
bootstrap with `-Z force-unstable-if-unmarked`. This flags serves a dual purpose
of forcing crates.io crates to themselves be unstable while also allowing them
to use other "unstable" crates.io crates. This should mean that adding a
dependency to compiler no longer requires upstream modification with
unstable/staged_api attributes for inclusion!
box large variants in MIR
Operand: 72 -> 24 B
Statement: 192 -> 96 B
Terminator: 256 -> 112 B
librustc translation memory usage: 1795 -> 1669 MB
next step would be interning lvalues, I suppose?
cc #36799 (@urschrei - does ostn15_phf compile with this PR?)
r? @eddyb
Removes unused macros from:
* libcore
* libcollections
The last use of these two macros was removed in commit
b64c9d5670
when the char_range_at_reverse function was been removed.
* librustc_errors
Their last use was removed by commits
2f2c3e1783
and 11dc974a38.
* libsyntax_ext
* librustc_trans
Also, put the otry macro in back/msvc/mod.rs under the
same cfg argument as the places that use it.
Operand: 72 -> 24 B
Statement: 192 -> 96 B
Terminator: 256 -> 112 B
librustc translation memory usage: 1795 -> 1669 MB
next step would be interning lvalues, I suppose?
Add RWPI/ROPI relocation model support
This PR adds support for using LLVM 4's ROPI and RWPI relocation models for ARM.
ROPI (Read-Only Position Independence) and RWPI (Read-Write Position Independence) are two new relocation models in LLVM for the ARM backend ([LLVM changset](https://reviews.llvm.org/rL278015)). The motivation is that these are the specific strategies we use in userspace [Tock](https://www.tockos.org) apps, so supporting this is an important step (perhaps the final step, but can't confirm yet) in enabling userspace Rust processes.
## Explanation
ROPI makes all code and immutable accesses PC relative, but not assumed to be overriden at runtime (so for example, jumps are always relative).
RWPI uses a base register (`r9`) that stores the addresses of the GOT in memory so the runtime (e.g. a kernel) only adjusts r9 tell running code where the GOT is.
## Complications adding support in Rust
While this landed in LLVM master back in August, the header files in `llvm-c` have not been updated yet to reflect it. Rust replicates that header file's version of the `LLVMRelocMode` enum as the Rust enum `llvm::RelocMode` and uses an implicit cast in the ffi to translate from Rust's notion of the relocation model to the LLVM library's notion.
My workaround for this currently is to replace the `LLVMRelocMode` argument to `LLVMTargetMachineRef` with an int and using the hardcoded int representation of the `RelocMode` enum. This is A Bad Idea(tm), but I think very nearly the right thing.
Would a better alternative be to patch rust-llvm to support these enum variants (also a fairly trivial change)?
