Was browsing somebody else's code and came across a snippet using labels. Looking around, it seems like there was an example for this in [rustbyexample](http://rustbyexample.com/flow_control/loop/nested.html) but none in trpl.
Visual Studio 2015, recently released, includes the Universal CRT, a different
flavor than was provided before. The binaries and header files for this library
are included in new locations not previously known about by gcc-rs, and this
commit adds support for the necessary probing to find these.
Unfortunately there are no prior examples of this probing to be found in
frameworks like CMake or clang, so this is done is a bit of a sketchy method
today. It assumes that the installation is in a relatively standard format and
then blindly looks for the location of the UCRT. I'd love to switch this over to
using registry keys for probing, but I was currently unable to find such keys.
This should enable the compiler to work outside VS 2015 dev tools prompts.
Refactors the "desugaring" of closures to expose the types of the upvars. This is necessary to be faithful with how actual structs work. The reasoning of the particular desugaring that I chose is explained in a fairly detailed comment.
As a side-effect, recursive closure types are prohibited unless a trait object intermediary is used. This fixes#25954 and also eliminates concerns about unrepresentable closure types that have infinite size, I believe. I don't believe this can cause regressions because of #25954.
(As for motivation, besides #25954 etc, this work is also intended as refactoring in support of incremental compilation, since closures are one of the thornier cases encountered when attempting to split node-ids into item-ids and within-item-ids. The goal is to eliminate the "internal def-id" distinction in astdecoding. However, I have to do more work on trans to really make progress there.)
r? @nrc
the object trait matches the required trait during trait selection. The
existing code was checking that the object trait WOULD match (in a
probe), but never executing the match outside of a probe.
This corrects various regressions observed in the wild, including
issue #26952. Fixes#26952.
Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol.
Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].)
[RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
Part of #22181
Replaced PR #26180.
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.
is being used now before the final regionck stage and in some cases SOME
amount of unresolved inference is OK. In fact, we could probably just
allow inference variables as well with only minimal pain.
TyClosure variant; thread this through wherever closure substitutions
are expected, which leads to a net simplification. Simplify trans
treatment of closures in particular.
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.
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.
[details]: https://github.com/rust-lang/rust/issues/26591#issuecomment-123513631
cc #26591
Adds support to the configure script for detecting Visual Studio 2015 being
installed and builds LLVM/uses cl with that compiler. The compiler will
automatically use this MSVC linker anyway because it's the highest version.
Makes the lint a bit more accurate, and improves the quality of the diagnostic
messages by explicitly returning an error message.
The new lint is also a little more aggressive: specifically, it now
rejects tuples, and it recurses into function pointers.
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.
