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`.)
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.
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.
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.
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 😄
r? @pnkfelix
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.
Closes#22642
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.
thoughts @alexcrichton @aturon @aidanhs ?
