Rollup merge of #32682 - petrochenkov:field3, r=Manishearth
The AST part of https://github.com/rust-lang/rust/pull/31937
Unlike HIR, AST still uses `Option` for field names because parser can't know field indexes reliably due to constructions like
```
struct S(#[cfg(false)] u8, u8); // The index of the second field changes from 1 during parsing to 0 after expansion.
```
and I wouldn't like to put the burden of renaming fields on expansion passes and syntax extensions.
plugin-[breaking-change] cc https://github.com/rust-lang/rust/issues/31645
r? @Manishearth
Auto merge of #32688 - jseyfried:ast_groundwork_for_1422, r=pnkfelix
[breaking-batch] Add support for `pub(restricted)` syntax in the AST
This PR allows the AST to represent the `pub(restricted)` syntax from RFC 1422 (cc #32409).
More specifically, it makes `ast::Visibility` non-`Copy` and adds two new variants, `Visibility::Crate` for `pub(crate)` and `Visitibility::Restricted { path: P<Path>, id: NodeId }` for `pub(path)`.
Auto merge of #32415 - alexcrichton:android-signal, r=alexcrichton
std: Fix linking against `signal` on Android
Currently the minimum supported Android version of the standard library is
API level 18 (android-18). Back in those days [1] the `signal` function was
just an inline wrapper around `bsd_signal`, but starting in API level
android-20 the `signal` symbols was introduced [2]. Finally, in android-21
the API `bsd_signal` was removed [3].
Basically this means that if we want to be binary compatible with multiple
Android releases (oldest being 18 and newest being 21) then we need to check
for both symbols and not actually link against either.
This was first discovered in rust-lang/libc#236 with a fix proposed in
rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so
Rust crates at large continue to be compatible with newer releases of Android
and crates, like the standard library, that want to opt into older support can
continue to do so via similar means.
trans: don't declare symbols that were already imported.
Fixes #32740 by checking for a declaration before attempting a new one.
Before, `LLVMGetOrInsertFunction` was called for a existing import, but with a different type.
The returned value was a cast function pointer instead of a declaration, and we gave this
value to `llvm::SetFunctionCallConv` & friends , which triggered an LLVM assertion.
Rollup merge of #32678 - mitaa:rdoc-stripped, r=alexcrichton
rustdoc: make rustdoc less pass-aware
Instead of hardcoding knowledge about the strip-private pass into the
rendering process we represent (some) stripped items as `ItemEnum::StrippedItem`.
Rustdoc will, for example, generate redirect pages for public items
contained in private modules which have been re-exported to somewhere
externally reachable - this will now not only work for the `strip-private`
pass, but for other passes as well, such as the `strip-hidden` pass.
Rollup merge of #32596 - soltanmm:lazy, r=nikomatsakis
Plumb obligations through librustc/infer
Like #32542, but more like #31867.
TODO before merge: make an issue for the propagation of obligations through... uh, everywhere... then replace the `#????`s with the actual issue number.
Auto merge of #29463 - jseyfried:master, r=nikomatsakis
Remove implicit binder from `FnSpace` in `VecPerParamSpace` (fixes #20526)
This removes the implicit binder from `FnSpace` in `VecPerParamSpace` so that `Binder<T>` is the only region binder (as described in issue #20526), and refactors away `enter_region_binder` and `exit_region_binder` from `TypeFolder`.
Alex Crichton [Mon, 21 Mar 2016 23:54:53 +0000 (16:54 -0700)]
std: Fix linking against `signal` on Android
Currently the minimum supported Android version of the standard library is
API level 18 (android-18). Back in those days [1] the `signal` function was
just an inline wrapper around `bsd_signal`, but starting in API level
android-20 the `signal` symbols was introduced [2]. Finally, in android-21
the API `bsd_signal` was removed [3].
Basically this means that if we want to be binary compatible with multiple
Android releases (oldest being 18 and newest being 21) then we need to check
for both symbols and not actually link against either.
This was first discovered in rust-lang/libc#236 with a fix proposed in
rust-lang/libc#237. I suspect that we'll want to accept rust-lang/libc#237 so
Rust crates at large continue to be compatible with newer releases of Android
and crates, like the standard library, that want to opt into older support can
continue to do so via similar means.
Auto merge of #32328 - jseyfried:coherence, r=nikomatsakis
resolve: Improve import failure detection and lay groundwork for RFC 1422
This PR improves import failure detection and lays some groundwork for RFC 1422.
More specifically, it
- Avoids recomputing the resolution of an import directive's module path.
- Refactors code in `resolve_imports` that does not scale to the arbitrarily many levels of visibility that will be required by RFC 1422.
- Replaces `ModuleS`'s fields `public_glob_count`, `private_glob_count`, and `resolved_globs` with a list of glob import directives `globs`.
- Replaces `NameResolution`'s fields `pub_outstanding_references` and `outstanding_references` with a field `single_imports` of a newly defined type `SingleImports`.
- Improves import failure detection by detecting cycles that include single imports (currently, only cycles of globs are detected). This fixes #32119.
Auto merge of #32647 - Amanieu:checked_atomic_intrinsics, r=eddyb
Only allow using the atomic intrinsics on integer types
Using these with non-integer types results in LLVM asserts. Atomic operations on non-integer types will require values be transmuted into an integer type of suitable size.
This doesn't affect the standard library since `AtomicBool` and `AtomicPtr` currently use `usize` for atomic operations.
Niko Matsakis [Tue, 29 Mar 2016 20:33:50 +0000 (16:33 -0400)]
fix corner case around top of stack
When deciding on a coinductive match, we were examining the new
obligation and the backtrace, but not the *current* obligation that goes
in between the two. Refactoring the code to just have the cycle given
as input also made things a lot simpler.
Auto merge of #32644 - oli-obk:check_all_constants_early, r=nrc
check constants even if they are not used in the current crate
For now this is just a `warn`-by-default lint. I suggest to make it a `deny`-by-default lint in the next release cycle (so no dependencies break), and then in another release cycle move to an error.
Auto merge of #32210 - Aatch:mir-traversal, r=nikomatsakis
rBreak Critical Edges and other MIR work
This PR is built on top of #32080.
This adds the basic depth-first traversals for MIR, preorder, postorder and reverse postorder. The MIR blocks are now translated using reverse postorder. There is also a transform for breaking critical edges, which includes the edges from `invoke`d calls (`Drop` and `Call`), to account for the fact that we can't add code after an `invoke`. It also stops generating the intermediate block (since the transform essentially does it if necessary already).
The kinds of cases this deals with are difficult to produce, so the test is the one I managed to get. However, it seems to bootstrap with `-Z orbit`, which it didn't before my changes.
Auto merge of #32168 - alexcrichton:fix-filecheck, r=aturon
mk: Add configure option for disabling codegen tests
Our `codegen` test suite requires the LLVM `FileCheck` utility but unfortunately
this isn't always available in all custom LLVM roots (e.g. those specified via
`--llvm-root`). This commit adds a `./configure` option called
`--disable-codegen-tests` which will manually disable running these tests. In
the case that this option is passed we can forgo the need for the `FileCheck`
executable. Note that we still require `FileCheck` by default as we will attempt
to run these tests.
Alex Crichton [Thu, 10 Mar 2016 03:11:02 +0000 (19:11 -0800)]
mk: Add configure option for disabling codegen tests
Our `codegen` test suite requires the LLVM `FileCheck` utility but unfortunately
this isn't always available in all custom LLVM roots (e.g. those specified via
`--llvm-root`). This commit adds a `./configure` option called
`--disable-codegen-tests` which will manually disable running these tests. In
the case that this option is passed we can forgo the need for the `FileCheck`
executable. Note that we still require `FileCheck` by default as we will attempt
to run these tests.
Stop accepting declarations when looking for definitions
eternally_available linkage isn't legal for declarations anyway, so the
check for an externally_available declaration should never succeed, so
let's remove it.
Auto merge of #32598 - alexcrichton:rustbuild-osx, r=aturon
rustbuild: Fix compile on OSX for 10.7
This commit should help configure our OSX rustbuild builder for targeting 10.7.
A key part of this is using `libc++` instead of `libstdc++` as apparently it's
more filled out and otherwise LLVM's cmake configuration would fail.
Auto merge of #32562 - ben0x539:bug-macro, r=nikomatsakis
librustc: Add bug!(), bug_span!() macros as unified entry points for internal compiler errors
The macros pass `file!()`, `line!()` and `format_args!(...)` on to a cold, never-inlined function, ultimately calling `session::{span_,}bug_fmt` via the tcx in tls or, failing that, panicking directly.
Like the comment on `Context` explains, `Context` is supposed to be
lightweight, so we're putting everything that's immutable after
creation of the Context behind an `Arc<SharedContext>`.
mitaa [Thu, 31 Mar 2016 16:15:54 +0000 (18:15 +0200)]
Make the rendering process less pass-aware
Instead of hardcoding knowledge about the strip-private pass into the
rendering process we represent (some) stripped items as `ItemEnum::StrippedItem`.
Rustdoc will, for example, generate redirect pages for public items
contained in private modules which have been re-exported to somewhere
externally reachable - this will now not only work for the `strip-private`
pass, but for other passes as well, such as the `strip-hidden` pass.
Auto merge of #32549 - respeccing:rust_backtrace_disabled, r=alexcrichton
allow RUST_BACKTRACE=0 to act as if unset
**UPDATE:** `RUST_BACKTRACE=0` to act as if the env. var is unset! (now `0` is what `disabled` was for, below)
When RUST_BACKTRACE is set to "disabled" then this acts as if the env. var is unset. So, either make sure `RUST_BACKTRACE` is not set OR set it to `disabled` to achieve the same effect.
Sample usage:
```bash
$ rustc -o /tmp/a.out -- <(echo 'fn main(){ panic!() }') && RUST_BACKTRACE=disabled /tmp/a.out
!! executing '/home/zazdxscf/build/1nonpkgs/rust/rust//x86_64-unknown-linux-gnu/stage2/bin//rustc' with args: '-o /tmp/a.out -- /dev/fd/63'
thread '<main>' panicked at 'explicit panic', /dev/fd/63:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Some programs(eg. [vim's syntactic](https://github.com/scrooloose/syntastic) used by [rust.vim](https://github.com/rust-lang/rust.vim)) cannot unset the env. var RUST_BACKTRACE if it's already set(eg. in .bashrc) but [they can set it to some value](https://github.com/respeccing/gentooskyline/blob/cb5533e1598f871d3fdf7c3d8248ce767b5b9360/system/Z575/OSes/gentoo/on_baremetal/filesystem_now/gentoo/home/zazdxscf/build/1nonpkgs/rust.vim/upd#L17), and I needed to ensure the env. var is unset in order to avoid this issue: https://github.com/rust-lang/rust/issues/29293
Auto merge of #32544 - alexcrichton:rustbuild-dist-libtest, r=brson
rustbuild: Fix dist for non-host targets
The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.
There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.
These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.
The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).
All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.
Alex Crichton [Mon, 28 Mar 2016 05:28:10 +0000 (22:28 -0700)]
rustbuild: Fix dist for non-host targets
The `rust-std` package that we produce is expected to have not only the standard
library but also libtest for compiling unit tests. Unfortunately this does not
currently happen due to the way rustbuild is structured.
There are currently two main stages of compilation in rustbuild, one for the
standard library and one for the compiler. This is primarily done to allow us to
fill in the sysroot right after the standard library has finished compiling to
continue compiling the rest of the crates. Consequently the entire compiler does
not have to explicitly depend on the standard library, and this also should
allow us to pull in crates.io dependencies into the build in the future because
they'll just naturally build against the std we just produced.
These phases, however, do not represent a cross-compiled build. Target-only
builds also require libtest, and libtest is currently part of the
all-encompassing "compiler build". There's unfortunately no way to learn about
just libtest and its dependencies (in a great and robust fashion) so to ensure
that we can copy the right artifacts over this commit introduces a new build
step, libtest.
The new libtest build step has documentation, dist, and link steps as std/rustc
already do. The compiler now depends on libtest instead of libstd, and all
compiler crates can now assume that test and its dependencies are implicitly
part of the sysroot (hence explicit dependencies being removed). This makes the
build a tad less parallel as in theory many rustc crates can be compiled in
parallel with libtest, but this likely isn't where we really need parallelism
either (all the time is still spent in the compiler).
All in all this allows the `dist-std` step to depend on both libstd and libtest,
so `rust-std` packages produced by rustbuild should start having both the
standard library and libtest.
Stop accepting declarations when looking for definitions
eternally_available linkage isn't legal for declarations anyway, so the
check for an externally_available declaration should never succeed, so
let's remove it.
Rollup merge of #32622 - tyoc213:rust-beginners, r=alexcrichton
Book: in beginner guide change irc channel #rust → #rust-beginners
I also would like to add the reference on the first README.md
Some like
```
most popular channel is [#rust], a venue for general discussion about
-Rust, and a good place to ask for help.
+Rust. And a good place to ask for help would be [#rust-beginners].
Auto merge of #32586 - seanmonstar:speialize-to-string, r=alexcrichton
specialize ToString for str
If there was some conditional compiling we could do, such that this impl only exists in nightly, and is turned off in beta/stable, I think that'd be an improvement here, as we could test specialization out without affecting stable builds.
Emanuel Czirai [Mon, 28 Mar 2016 12:41:55 +0000 (14:41 +0200)]
allow RUST_BACKTRACE=0 to act as if unset
/# This is a combination of 16 commits.
/# The first commit's message is:
allow RUST_BACKTRACE=disabled to act as if unset
When RUST_BACKTRACE is set to "disabled" then this acts as if the env.
var is unset.
/# This is the 2nd commit message:
case insensitive "DiSaBLeD" RUST_BACKTRACE value
previously it expected a lowercase "disabled" to treat the env. var as
unset
/# This is the 3rd commit message:
RUST_BACKTRACE=0 acts as if unset
previously RUST_BACKTRACE=disabled was doing the same thing
/# This is the 4th commit message:
RUST_BACKTRACE=0|n|no|off acts as if unset
previously only RUST_BACKTRACE=0 acted as if RUST_BACKTRACE was unset
Now added more options (case-insensitive): 'n','no' and 'off'
eg. RUST_BACKTRACE=oFF
/# This is the 5th commit message:
DRY on the value of 2
DRY=don't repeat yourself
Because having to remember to keep the two places of '2' in sync is not
ideal, even though this is a simple enough case.
projects / rust.git / log