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 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
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.
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).
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.
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`.)
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.
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).
Sidestep warning about repeated E0045 `span_err!` invocation.
(That is, take the two expressions with the same message and unify them into one subroutine.)
Updated "Installing Rust" and "After installation" to provide additional guidance to Windows users on including Rust in the Path system variable.
r? @steveklabnik
These provide various special readers, so point their docs to their
constructor functions in a manner consistent with everything else.
r? @alexcrichton
This is a resubmission of my previous git failure - apologies. Just fixing up a wording error that was discovered in E0253 after the r.
r? @Manishearth
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.
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.
Fixes#26210.
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.
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
