Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`.
(Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.)
----
Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
Auto merge of #27227 - eternaleye:patch-1, r=alexcrichton
Currently, `rustc` generates nondeterministic archives, which contain system timestamps. These don't really serve any useful purpose, and enabling deterministic archives moves us a little closer to completely deterministic builds. For a small toy library using `std::ops::{Deref,DerefMut}`, this change actually results in a bit-for-bit identical build every time.
Auto merge of #27208 - alexcrichton:msvc-less-dllimport, r=brson
Currently you can hit a link error on MSVC by only referencing static items from
a crate (no functions for example) and then link to the crate statically (as all
Rust crates do 99% of the time). A detailed investigation can be found [on
github][details], but the tl;dr is that we need to stop applying dllimport so
aggressively.
This commit alters the application of dllimport on constants to only cases where
the crate the constant originated from will be linked as a dylib in some output
crate type. That way if we're just linking rlibs (like the motivation for this
issue) we won't use dllimport. For the compiler, however, (which has lots of
dylibs) we'll use dllimport.
Auto merge of #27224 - alexcrichton:configure-lto-right, r=brson
The LTO pass in the compiler forgot to call the `LLVMRustAddBuilderLibraryInfo`
function and configure other options such as merge_functions, vectorize_slp,
etc. This ended up causing linker errors on MSVC targets because the optimizer
didn't have the right knowledge that some system functions are missing on these
platforms.
This commit consolidates creation of PassManagerBuilder instances to one
function which is then called when needed. This ensures that the pass manager is
always correctly configured with the various target-specific information that
LLVM needs.
Overall, this fixes `-C lto -C opt-level=3` on 32-bit MSVC targets.
Auto merge of #27221 - dotdash:no_empty_clean, r=luqmana
When compiling libsyntax this removes about 30k basic blocks that only
contain a single unconditional jump and reduces the peak memory usage by
about 10MB (from 681MB down to 671MB).
Currently, `rustc` generates nondeterministic archives, which contain system timestamps. These don't really serve any useful purpose, and enabling deterministic archives moves us a little closer to completely deterministic builds. For a small toy library using `std::ops::{Deref,DerefMut}`, this change actually results in a bit-for-bit identical build every time.
Auto merge of #27192 - dotdash:inline_eq_slice, r=luqmana
eq_slice_() used to be a common implementation for two function that
both called it, but of those only eq_slice() is left, so we can as well
directly inline the code.
Auto merge of #27191 - pnkfelix:sidestep-unary-negate-warning, r=alexcrichton
Work around unary negation to-be-feature-gated warning by replacing references to `-1` as a `ast::NodeId` with `ast::DUMMY_NODE_ID`, which seems like a better notation to use (it is currently also `-1`.
(AFAICT the code is not *relying* on the value `-1` anywhere, it really just needed a dummy value for when the input is `None`.)
Alex Crichton [Wed, 22 Jul 2015 23:22:51 +0000 (16:22 -0700)]
trans: Consolidate creating pass manager builders
The LTO pass in the compiler forgot to call the `LLVMRustAddBuilderLibraryInfo`
function and configure other options such as merge_functions, vectorize_slp,
etc. This ended up causing linker errors on MSVC targets because the optimizer
didn't have the right knowledge that some system functions are missing on these
platforms.
This commit consolidates creation of PassManagerBuilder instances to one
function which is then called when needed. This ensures that the pass manager is
always correctly configured with the various target-specific information that
LLVM needs.
Overall, this fixes `-C lto -C opt-level=3` on 32-bit MSVC targets.
Björn Steinbrink [Wed, 22 Jul 2015 21:15:01 +0000 (23:15 +0200)]
Avoid creating basic blocks for empty cleanup scopes
When compiling libsyntax this removes about 30k basic blocks that only
contain a single unconditional jump and reduces the peak memory usage by
about 10MB (from 681MB down to 671MB).
Steve Klabnik [Wed, 22 Jul 2015 16:56:49 +0000 (12:56 -0400)]
Rollup merge of #27155 - steveklabnik:doc_std_io_buf_writer, r=alexcrichton
Mostly through adding examples.
r? @alexcrichton
I'm going to be doing a bunch of these today, but I figured I'd keep it one PR per struct, since the last 'all the things in one PR' ended up taking a week to actually land.
Add actual use of the `struct Structure` lying dormant in `new-box-syntax.rs`.
The original test program exercised the (garbage-collected heap)
allocation form `box (GC) ...`, feeding an instance of `Structure` in
as the expression. This obviously went away when `GC` went away, but
there's no reason for us not to include an appropriate unit test here
for the same form, just for heap-allocated instances of `Structure`.
Factor feature gate tests for box syntax into two separate files.
The two tests are separate since the current implementation performs
the feature gate checks at distinct phases in the compilation, with an
`abort_if_errors` calls separating them.
Allow unstable code to be injected by placement-`in` expansion.
(Over time the stability checking has gotten more finicky; in
particular one must attach the (whole) span of the original `in PLACE
BLOCK` expression to the injected references to unstable paths, as
noted in the comments.)
call `push_compiler_expansion` during the placement-`in` expansion.
Hack for "unsafety hygiene" -- `push_unsafe!` and `pop_unsafe!`.
Even after expansion, the generated expressions still track depth of
such pushes (i.e. how often you have "pushed" without a corresponding
"pop"), and we add a rule that in a context with a positive
`push_unsafe!` depth, it is effectively an `unsafe` block context.
(This way, we can inject code that uses `unsafe` features, but still
contains within it a sub-expression that should inherit the outer
safety checking setting, outside of the injected code.)
This is a total hack; it not only needs a feature-gate, but probably
should be feature-gated forever (if possible).
ignore-pretty in test/run-pass/pushpop-unsafe-okay.rs
Auto merge of #26683 - eefriedman:const-eval-hint, r=pnkfelix
The "hint" mechanism is essentially used as a workaround to compute
types for expressions which have not yet been type-checked. This
commit clarifies that usage, and limits the effects to the places
where it is currently necessary.
Auto merge of #27176 - alexcrichton:fix-stock-llvm, r=brson
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:
* LLVM changes its IR syntax from time to time, so it's very difficult to
have these files build across many LLVM versions simultaneously. We'll likely
want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
itself, so it makes sense to fold it into a location which can do more
platform-specific checks for various implementation details (such as MSVC 32
vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
end up becoming very useful if we move towards building the standard library
with Cargo.
In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
Alex Crichton [Wed, 22 Jul 2015 00:31:35 +0000 (17:31 -0700)]
trans: Be a little more picky about dllimport
Currently you can hit a link error on MSVC by only referencing static items from
a crate (no functions for example) and then link to the crate statically (as all
Rust crates do 99% of the time). A detailed investigation can be found [on
github][details], but the tl;dr is that we need to stop applying dllimport so
aggressively.
This commit alters the application of dllimport on constants to only cases where
the crate the constant originated from will be linked as a dylib in some output
crate type. That way if we're just linking rlibs (like the motivation for this
issue) we won't use dllimport. For the compiler, however, (which has lots of
dylibs) we'll use dllimport.
Auto merge of #27185 - pnkfelix:test-cyclic-collections, r=alexcrichton
This test attempts to exercise cyclic structure in much of `std::collections`
(as much as is possible; e.g. things like `EnumSet` and `BitVec` do not really support carrying references at all, so trying to represent cyclic structure within them dooes not really make sense.)
This work should land before we make future revisions to `dropck`; that is, I am attempting to catch potential regressions to cases where we supported cyclic structure circa Rust 1.2.
Alex Crichton [Mon, 20 Jul 2015 20:27:38 +0000 (13:27 -0700)]
trans: Move rust_try into the compiler
This commit moves the IR files in the distribution, rust_try.ll,
rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main
distribution. There's a few reasons for this change:
* LLVM changes its IR syntax from time to time, so it's very difficult to
have these files build across many LLVM versions simultaneously. We'll likely
want to retain this ability for quite some time into the future.
* The implementation of these files is closely tied to the compiler and runtime
itself, so it makes sense to fold it into a location which can do more
platform-specific checks for various implementation details (such as MSVC 32
vs 64-bit).
* This removes LLVM as a build-time dependency of the standard library. This may
end up becoming very useful if we move towards building the standard library
with Cargo.
In the immediate future, however, this commit should restore compatibility with
LLVM 3.5 and 3.6.
Auto merge of #27093 - Manishearth:closure-label-shadow, r=pnkfelix
Fixes #25343
To be honest I'm not sure if this is the right fix (I haven't yet fully understood the code),
but it seems to work. I'll look closer at the code when I have some time, in the meantime if this
is the right fix it would be nice to get verification from someone who does understand the code :smile:
Auto merge of #27073 - alexcrichton:less-proc-fs, r=brson
This can fail on linux for various reasons, such as the /proc filesystem not
being mounted. There are already many cases where we can't set up stack guards,
so just don't worry about this case and communicate that no guard was enabled.
I've confirmed that this allows the compiler to run in a chroot without /proc
mounted.
Auto merge of #26856 - steveklabnik:gh26475, r=alexcrichton
Fixes #26475
I'm not sure this is enough, really, but I'm not totally clear on what specific information would be valuable here. In the original issue, the Java page was pretty decent, but now I can't think of a different way to word it, and copying their prose is of course not acceptable.