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 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`.
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.
(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.
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
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
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
