This commit spawns the emulator in the same way as buildbot with `nohup` to hope
that it goes into the background successfully, followed by a `wait-for-device`
command. I'm not actually sure if this'll fix the problems we're seeing, but I
figure it can't hurt to test out.
bors [Wed, 28 Dec 2016 20:19:39 +0000 (20:19 +0000)]
Auto merge of #38449 - eddyb:lazy-10, r=nikomatsakis
[10/n] Split constants and functions' arguments into disjoint bodies.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/38053) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
Finishes the signature-body split started in #37918, namely:
* `trait` items are separated just like `impl` items were, for uniformity, closing #37712
* `static`s, `const`s (including associated ones), `enum` discriminants and array lengths get bodies
* even the count in "repeat expressions", i.e. `n` in `[x; n]`, which fixes #24414
* arguments' patterns are moved to the bodies, with the types staying in `FnDecl`
* `&self` now desugars to `self: &Self` instead of `self: &_` (similarly for other `self` forms)
* `astconv`'s and metadata's (for rustdoc) informative uses are explicitly ignored for the purposes of the dep graph. this could be fixed in the future by hashing the exact information being extracted about the arguments as opposed to generating a dependency on *the whole body*
bors [Wed, 28 Dec 2016 17:27:13 +0000 (17:27 +0000)]
Auto merge of #38639 - xen0n:nightly-dist-hotfix, r=brson
rustbuild: Hotfix to unbreak nightly
Fixes an oversight unnoticed in #38468 that eventually broke nightly packaging. I didn't realize this until some moments ago, when I finally found out the failure is actually deterministic. Many apologies for eating 3 nightlies during the holidays.
bors [Wed, 28 Dec 2016 14:33:48 +0000 (14:33 +0000)]
Auto merge of #38626 - redox-os:args_fix, r=alexcrichton
Fix argument handling on Redox
After switching the start code to be handled in libc, we are no longer passing in slices as arguments into the libstd main function. This means that handling had to be rewritten to match the unix way of doing things.
Additional commits on this branch are going to be merged in this PR: https://github.com/rust-lang/rust/pull/38577#issuecomment-269138394
bors [Wed, 28 Dec 2016 09:42:46 +0000 (09:42 +0000)]
Auto merge of #38616 - pnkfelix:refactor-mir-dataflow-remove-ctxt, r=arielb1
Refactor mir::dataflow: remove Ctxt associated type from BitDenotation trait
Refactor mir::dataflow: remove Ctxt associated type from BitDenotation trait
I no longer remember why I needed this (or thought I did). The way
that the `BitDenotation` is passed around in all existing use cases
(and planned future ones), the thing that were in the `Ctxt` can just
be part of `Self` instead.
(I think ariel had been pushing me to do this back when I first put in
this infrastructure; it took me a while to see how much of pain the
`Ctxt` was causing.)
bors [Wed, 28 Dec 2016 07:05:07 +0000 (07:05 +0000)]
Auto merge of #38589 - aidanhs:aphs-stage0-rustdoc-test, r=alexcrichton
Teach `rustdoc --test` about `--sysroot`, pass it when testing rust
This permits rustdoc tests to work in stage0.
Logical continuation of #36586.
Snippet from https://github.com/rust-lang/rust/issues/38575#issuecomment-269090724:
> it should actually be possible to run all the libstd tests immediately after creating std of stage0-out - there's no reason to build librustc at all if you've just made a change to (for example) libcollections, `./x.py test src/libcollections --stage 0 -v --incremental` should just work
This PR makes it so (or appears to in my testing).
bors [Wed, 28 Dec 2016 04:12:11 +0000 (04:12 +0000)]
Auto merge of #38579 - whitequark:min_atomic_width, r=alexcrichton
Add a min_atomic_width target option, like max_atomic_width
Rationale: some ISAs, e.g. OR1K, do not have atomic instructions
for byte and halfword access, and at the same time do not have
a fixed endianness, which makes it unreasonable to implement these
through word-sized atomic accesses.
Wang Xuerui [Tue, 27 Dec 2016 17:49:25 +0000 (01:49 +0800)]
rustbuild: fix host-only rules ignoring targets in dist steps
`arr` is the actual list of targets participating in steps construction,
but due to #38468 the hosts array now consists of only the build triple
for the `dist` steps, hence all non-build-triple targets are lost for
the host-only rules.
Fix this by using the original non-shadowed hosts array in `arr`
calculation. This should unbreak the nightly packaging process.
Wang Xuerui [Tue, 27 Dec 2016 17:54:09 +0000 (01:54 +0800)]
rustbuild: clarify comment on target array calculation
The comment touched, as originally written, only concerned itself with
the `test` steps. However, since #38468 the `arr` variable actually has
gained an indirect relationship with the `dist` steps too. The comment
failed to convey the extra meaning, contributing to the misunderstanding
which eventually lead to #38637. Fix that by moving the comment into the
right place near the relevant condition, and properly documenting
`arr`'s purpose.
bors [Tue, 27 Dec 2016 02:18:20 +0000 (02:18 +0000)]
Auto merge of #38507 - alexcrichton:travis-lldb, r=brson
travis: Update the OSX image we run tests in
The current image is `xcode7.3`, Travis's current default. Unfortunately this
has a version of LLDB which doesn't support debuginfo-lldb tests (see #32520),
so we're not running LLDB tests on Travis yet.
This switches us to the newest image from Travis, `xcode8.2`, which should have
a newer version of LLDB we can run tests against.
Alex Crichton [Wed, 21 Dec 2016 03:34:57 +0000 (19:34 -0800)]
travis: Update the OSX image we run tests in
The current image is `xcode7.3`, Travis's current default. Unfortunately this
has a version of LLDB which doesn't support debuginfo-lldb tests (see #32520),
so we're not running LLDB tests on Travis yet.
This switches us to the newest image from Travis, `xcode8.2`, which should have
a newer version of LLDB we can run tests against.
Someone wants to attempt launching some Rust [into space](https://www.reddit.com/r/rust/comments/5h76oa/c_interop/) but their platform is based on the SPARCv8 architecture. Let's not block them by enabling LLVM's SPARC backend.
Something very important that they'll also need is the "cabi" stuff as they'll be embedding some Rust code into a bigger C application (i.e. heavy use of `extern "C"`). The question there is what name(s) should we use for "target_arch" as the "cabi" implementation [varies according to that parameter](https://github.com/rust-lang/rust/blob/1.13.0/src/librustc_trans/abi.rs#L498-L523).
AFAICT, SPARCv8 is a 32-bit architecture and SPARCv9 is a 64-bit architecture. And, LLVM uses `sparc`, `sparcv9` and `sparcel` for [the architecture triple](https://github.com/rust-lang/llvm/blob/ac1c94226e9fa17005ce7e2dd52dd6d1875f3137/include/llvm/ADT/Triple.h#L67-L69) so perhaps we should use `target_arch = "sparc"` (32-bit) and `target_arch = "sparcv9"` (64-bit) as well.
r? @alexcrichton This PR only enables this LLVM backend when rustbuild is used. Do I also need to implement this for the old Makefile-based build system? Or are all our nightlies now being generated using rustbuild?
This commit spawns the emulator in the same way as buildbot with `nohup` to hope
that it goes into the background successfully, followed by a `wait-for-device`
command. I'm not actually sure if this'll fix the problems we're seeing, but I
figure it can't hurt to test out.
Refactor mir::dataflow: remove Ctxt associated type from BitDenotation trait.
I no longer remember why I needed this (or thought I did). The way
that the `BitDenotation` is passed around in all existing use cases
(and planned future ones), the thing that were in the `Ctxt` can just
be part of `Self` instead.
(I think ariel had been pushing me to do this back when I first put in
this infrastructure; it took me a while to see how much of pain the
`Ctxt` was causing.)
bors [Mon, 26 Dec 2016 13:32:13 +0000 (13:32 +0000)]
Auto merge of #38154 - petrochenkov:altname, r=jseyfried
More systematic error reporting in path resolution
Path resolution for types, expressions and patterns used various heuristics to give more helpful messages on unresolved or incorrectly resolved paths.
This PR combines these heuristics and applies them to all non-import paths.
First a path is resolved in all namespaces, starting from its primary namespace (to give messages like "expected function, found macro, you probably forgot `!`").
If this resolution doesn't give a desired result we create a base error - either "path is not resolved" or "path is resolved, but the resolution is not acceptable in this context".
Other helps and notes are applied to this base error using heuristics.
Here's the list of heuristics for a path with a last segment `name` in order.
First we issue special messages for unresolved `Self` and `self`.
Second we try to find free items named `name` in other modules and suggest to import them.
Then we try to find fields and associated items named `name` and suggest `self.name` or `Self::name`.
After that we try several deterministic context dependent heuristics like "expected value, found struct, you probably forgot `{}`".
If nothing of the above works we try to find candidates with other names using Levenshtein distance.
---
Some alternatives/notes/unresolved questions:
- ~~I had a strong desire to migrate all affected tests to `test/ui`, diagnostics comparison becomes much more meaningful, but I did this only for few tests so far.~~ (Done)
- ~~Labels for "unresolved path" errors are mostly useless now, it may make sense to move some help/notes to these labels, help becomes closer to the error this way.~~ (Done)
- ~~Currently only the first successful heuristic results in additional message shown to the user, it may make sense to print them all, they are rarely compatible, so the diagnostics bloat is unlikely.~~ (Done)
- Now when https://github.com/rust-lang/rust/pull/38014 landed `resolve_path` can potentially be replaced with `smart_resolve_path` in couple more places - e.g. ~~visibilities~~ (done), ~~import prefixes~~ (done), HIR paths.
---
Some additional fixes:
- Associated suggestions and typo suggestions are filtered with a context specific predicate to avoid inapplicable suggestions.
- `adjust_local_def` works properly in speculative resolution.
- I also fixed a recently introduced ICE in partially resolved UFCS paths (see test `ufcs-partially-resolved.rs`). Minimal reproduction:
```
enum E {}
fn main() {
<u8 as E>::A;
}
```
Fixes https://github.com/rust-lang/rust/issues/38409, fixes https://github.com/rust-lang/rust/issues/38504 (duplicates).
- Some bugs in resolution of visibilities are fixed - `pub(Enum)`, `pub(Trait)`, `pub(non::local::path)`.
- Fixes https://github.com/rust-lang/rust/issues/38012.
---
r? @jseyfried for technical details + @jonathandturner for diagnostics changes
How to read the patch: `smart_resolve_path(_fragment)/resolve_qpath_anywhere` are written anew and replace `resolve_trait_reference`/`resolve_type`/`resolve_pattern_path`/`resolve_struct_path`/`resolve_expr` for `ExprKind::Path`, everything else can be read as a diff.
bors [Mon, 26 Dec 2016 00:47:50 +0000 (00:47 +0000)]
Auto merge of #38598 - brson:em, r=alexcrichton
Emscripten targets are Unix targets
I suspect this will fix the errors compiling libc https://buildbot.rust-lang.org/builders/auto-linux-rustbuild-cross-opt/builds/689/steps/compile/logs/stdio that are occurring on every PR.
Emscripten is basically a posix emulation layer for the web and I consider it a Unix.
Steve Klabnik [Sat, 24 Dec 2016 19:29:33 +0000 (14:29 -0500)]
Rollup merge of #38568 - chris-morgan:fix-markdown-lists, r=frewsxcv
Fix Markdown list formatting.
The Markdown engine used by the book can cope with a single leading space on the list marker:
Like this:
* List item
Rather than like this:
* List item
… but it’s not the typical convention employed in the book, and moreover the Markdown engine used for producing the error index *can’t* cope with it (its behaviour looks like a bug, as it appears to lose one of the two line breaks as well, but that’s immaterial here).
So, we shift to a single convention which doesn’t trigger bugs in the Markdown renderer.
----
See https://doc.rust-lang.org/error-index.html#E0458 and https://doc.rust-lang.org/error-index.html#E0101 for the bad current rendering in the error index.
Steve Klabnik [Sat, 24 Dec 2016 19:29:23 +0000 (14:29 -0500)]
Rollup merge of #38497 - QuietMisdreavus:rustdoc-where-again, r=steveklabnik
rustdoc: properly calculate line length for where clauses
Apparently, while I was cleaning up #37190, I regressed the formatting for long where clauses, where it wouldn't take the "prefix" length into account when deciding whether to break the line up. This patch fixes that.
Steve Klabnik [Sat, 24 Dec 2016 19:29:21 +0000 (14:29 -0500)]
Rollup merge of #38297 - matklad:linked-lists-are-not-cool, r=GuillaumeGomez
Advertise Vec in LinkedList docs
r? @steveklabnik
Hi! We already [advise](https://doc.rust-lang.org/std/collections/#use-a-linkedlist-when) to use `Vec` instead of `LinkedList` in the top-level collections documentation. But I think it may be missed by someone who just directly finds `LinkedList`.
What do you feel about advertising `Vec` directly in `LinkedList` docs as well?
Steve Klabnik [Sat, 24 Dec 2016 19:29:20 +0000 (14:29 -0500)]
Rollup merge of #38013 - wezm:simplify-test-notes, r=steveklabnik
Simplify notes on testing and concurrency
The start of the notes on tests running concurrently, added in https://github.com/rust-lang/rust/pull/37766 read a little awkwardly. This PR fixes that and simplifies the wording a bit.
bors [Sat, 24 Dec 2016 13:28:37 +0000 (13:28 +0000)]
Auto merge of #38062 - alexcrichton:fix-line-writer, r=brson
std: Fix partial writes in LineWriter
Previously the `LineWriter` could successfully write some bytes but then fail to
report that it has done so. Additionally, an erroneous flush after a successful
write was permanently ignored. This commit fixes these two issues by (a)
maintaining a `need_flush` flag to indicate whether a flush should be the first
operation in `LineWriter::write` and (b) avoiding returning an error once some
bytes have been successfully written.
whitequark [Mon, 15 Aug 2016 09:46:44 +0000 (09:46 +0000)]
Add a min_atomic_width target option, like max_atomic_width.
Rationale: some ISAs, e.g. OR1K, do not have atomic instructions
for byte and halfword access, and at the same time do not have
a fixed endianness, which makes it unreasonable to implement these
through word-sized atomic accesses.
bors [Sat, 24 Dec 2016 00:22:00 +0000 (00:22 +0000)]
Auto merge of #38268 - withoutboats:parse_where_higher_rank_hack, r=eddyb
Prevent where < ident > from parsing.
In order to be forward compatible with `where<'a>` syntax for higher
rank parameters, prevent potential conflicts with UFCS from parsing
correctly for the near term.
bors [Fri, 23 Dec 2016 21:36:59 +0000 (21:36 +0000)]
Auto merge of #38523 - camlorn:disable_field_reordering, r=nikomatsakis
Disable field reordering
This was decided via IRC and needs a backport to beta. Basically, #37429 broke servo, and probably needs an announcement and opt-in flag. I didn't run all tests locally but think I've already reverted all the ones that need to be reverted.
bors [Fri, 23 Dec 2016 18:43:12 +0000 (18:43 +0000)]
Auto merge of #38533 - jseyfried:legacy_custom_derive_deprecation, r=nrc
Allow legacy custom derive authors to disable warnings in downstream crates
This PR allows legacy custom derive authors to use a pre-deprecated method `registry.register_custom_derive()` instead of `registry.register_syntax_extension()` to avoid downstream deprecation warnings.
bors [Fri, 23 Dec 2016 09:09:26 +0000 (09:09 +0000)]
Auto merge of #38401 - redox-os:redox_cross, r=brson
Redox Cross Compilation
I will admit - there are things here that I wish I did not have to do. This completes the ability to create a cross compiler from the rust repository for `x86_64-unknown-redox`. I will document this PR with inline comments explaining some things.
bors [Fri, 23 Dec 2016 06:22:45 +0000 (06:22 +0000)]
Auto merge of #38232 - jseyfried:refactor_global_paths, r=nrc
Refactor global paths
This PR removes the field `global: bool` from `ast::Path` and `hir::Path`, instead representing a global path `::foo::bar` as `{{root}}::foo::bar`, where `{{root}}` is a virtual keyword `keywords::CrateRoot`.
projects / rust.git / log