Commit Graph

88678 Commits

Author SHA1 Message Date
Matthias Krüger
8c4a7a9701 submodules: update clippy from 1b89724b to 1838bfe5
Changes:
````
Fixing typo in CONTRIBUTING.md
Fix breakage due to rust-lang/rust#57651
Run rustfmt
Fixed breakage due to rust-lang/rust#57489
Fix breakage due to rust-lang/rust#57755
Catch up with `format_args` change
Fix bad `while_let_on_iterator` suggestion.
rustup https://github.com/rust-lang/rust/pull/57747
Fixing issues pointed out by dogfood tests.
Update to collect all the files then throw the error.
Adding a test for checking if test files are missing.
Remove bors.toml
add applicability to lint name suggestion
````
2019-01-21 02:58:57 +01:00
bors
e73069767f Auto merge of #57704 - lenoil98:patch-2, r=alexcrichton
Update bootstrap.py

Add PowerPC64 support on FreeBSD
2019-01-20 21:49:24 +00:00
bors
846ea58cd5 Auto merge of #56884 - euclio:codeblock-diagnostics, r=QuietMisdreavus
rustdoc: overhaul code block lexing errors

Fixes #53919.

This PR moves the reporting of code block lexing errors from rendering time to an early pass, so we can use the compiler's error reporting mechanisms. This dramatically improves the diagnostics in this situation: we now de-emphasize the lexing errors as a note under a warning that has a span and suggestion instead of just emitting errors at the top level.

Additionally, this PR generalizes the markdown -> source span calculation function, which should allow other rustdoc warnings to use better spans in the future.

Last, the PR makes sure that the code block is always emitted in the docs, even if it fails to highlight correctly.

Of note:
- The new pass unfortunately adds another pass over the docs to gather the doc blocks for syntax-checking. I wonder if this could be combined with the pass that looks for testable blocks? I'm not familiar with that code, so I don't know how feasible that is.
- `pulldown_cmark` doesn't make it easy to find the spans of the code blocks, so the code that calculates the spans is a little nasty. It works for all the test cases I threw at it, but I wouldn't be surprised if an edge case would break it. Should have a thorough review.
- This PR worsens the state of #56885, since those certain fatal lexing errors are now emitted before docs get generated at all.
2019-01-20 19:01:38 +00:00
bors
794e22862c Auto merge of #57697 - dotdash:fast_lex_reg_resol_item_bodies, r=nagisa
Use a faster early exit during region expansion

Turns out that the equality check for regions is rather expensive, and
the current early exit check works in such a way, that the comparison is
even done twice. As we only really care about the case of equal scopes,
we can perform a faster, more specialized check and move it up one
level, so we can eventually skip the additional full comparison as well.
2019-01-20 16:24:27 +00:00
bors
4db2394156 Auto merge of #57680 - cuviper:codegen-rebuild, r=Mark-Simulacrum
[rustbuild] Rebuild std after changes to codegen backends

Use `clear_if_dirty` on std for backend changes, just as we do for
changes to rustc itself, so new codegen is correctly applied to all
later compiler stages.

Fixes #48298.
2019-01-20 13:46:03 +00:00
bors
d38d6be336 Auto merge of #57655 - mtak-:fix-tls-dtors-macos, r=alexcrichton
OSX: fix #57534 registering thread dtors while running thread dtors

r? @alexcrichton

- "fast" `thread_local` destructors get run even on the main thread
- "fast" `thread_local` dtors, can initialize other `thread_local`'s

One corner case where this fix doesn't work, is when a C++ `thread_local` triggers the initialization of a rust `thread_local`.

I did not add any std::thread specific flag to indicate that the thread is currently exiting, which would be checked before registering a new dtor (I didn't really know where to stick that). I think this does the trick tho!

Let me know if anything needs tweaking/fixing/etc.

resolves this for macos: https://github.com/rust-lang/rust/issues/28129
fixes: https://github.com/rust-lang/rust/issues/57534
2019-01-20 11:08:37 +00:00
bors
2ab5d8ac44 Auto merge of #57651 - JohnTitor:give-char-type, r=estebank
Implement new literal type `Err`

Fixes #57384

I removed `return Ok`, otherwise, two errors occur. Any solutions?

r? @estebank
2019-01-20 08:26:12 +00:00
Yuki Okushi
4005d3a8cb Remove whitespace 2019-01-20 14:59:10 +09:00
Yuki Okushi
7ce2514419 Fix tests 2019-01-20 14:53:28 +09:00
Yuki Okushi
6e59c64326 Revert change 2019-01-20 14:53:16 +09:00
Yuki Okushi
a4ff1dcc53 Mark incorrect recovered char literals as TyErr to avoid type errors 2019-01-20 14:51:54 +09:00
bors
588f94b37d Auto merge of #57602 - alexcrichton:test-appveyor, r=alexcrichton
Remove GCE cloud setting from AppVeyor config

AppVeyor has informed us that this may no longer be necessary after some
infrastructure upgrades on their side, so let's see how this goes!
2019-01-20 04:16:42 +00:00
bors
0c0c585281 Auto merge of #57761 - Centril:rollup, r=Centril
Rollup of 4 pull requests

Successful merges:

 - #57452 (Improve docs for Formatter)
 - #57689 (Redo `hir::Stmt`)
 - #57723 (Point at cause for expectation in return type type error)
 - #57736 (Remove delay_span_bug from qualify_min_const_fn)

Failed merges:

r? @ghost
2019-01-19 21:21:12 +00:00
Yuki Okushi
e9af312932 [WIP] Fix tests 2019-01-20 04:37:58 +09:00
Yuki Okushi
c502a79fa1 [WIP] Improve error behavior 2019-01-20 04:37:29 +09:00
Mazdak Farrokhzad
d27224e0d8
Rollup merge of #57736 - phansch:remove_delay, r=oli-obk
Remove delay_span_bug from qualify_min_const_fn

This is causing issues with a new Clippy lint that will be able to
detect possible const functions.

As per https://github.com/rust-lang/rust-clippy/pull/3648#discussion_r247927450

r? @oli-obk
2019-01-19 19:41:24 +01:00
Mazdak Farrokhzad
5b9e02a39c
Rollup merge of #57723 - estebank:fix, r=davidtwco
Point at cause for expectation in return type type error

Various improvements and fixes for type errors in return expressions.

Fix #57664.
2019-01-19 19:41:22 +01:00
Mazdak Farrokhzad
3bc61cd13c
Rollup merge of #57689 - nnethercote:redo-hir-Stmt, r=petrochenkov
Redo `hir::Stmt`

A couple of changes that make things simpler and more consistent.

This should probably wait until after 1.32 lands to land, to avoid late breakage for tools.
2019-01-19 19:41:21 +01:00
Mazdak Farrokhzad
286ce3c36a
Rollup merge of #57452 - steveklabnik:improve-formatter-docs, r=frewsxcv
Improve docs for Formatter

Some improvements to `std::fmt::Formatter` to make it a bit more consistent with other documentation, as well as calling out that you don't ever instantiate one yourself.
2019-01-19 19:41:20 +01:00
bors
52fec814db Auto merge of #57721 - ehuss:update-cargo, r=alexcrichton
Update cargo

Unblocks #56884  cc @euclio

6 commits in 2b4a5f1f0bb6e13759e88ea9512527b0beba154f..ffe65875fd05018599ad07e7389e99050c7915be
2019-01-12 04:13:12 +0000 to 2019-01-17 23:57:50 +0000
- Better error message for bad manifest with `cargo install`. (rust-lang/cargo#6560)
- relax rustdoc output assertion (rust-lang/cargo#6559)
- touch some files when we use them (rust-lang/cargo#6477)
- Add documentation for new package/publish feature flags. (rust-lang/cargo#6553)
- Update chat link to Discord. (rust-lang/cargo#6554)
- Fix typo (rust-lang/cargo#6552)

r? @alexcrichton
2019-01-19 18:37:03 +00:00
bors
93234994b8 Auto merge of #57755 - Centril:rollup, r=Centril
Rollup of 7 pull requests

Successful merges:

 - #57486 (Simplify `TokenStream` some more)
 - #57502 (make trait-aliases work across crates)
 - #57598 (Add missing unpretty option help message)
 - #57649 (privacy: Account for associated existential types)
 - #57659 (Fix release manifest generation)
 - #57699 (add applicability to remaining suggestions)
 - #57719 (Tweak `expand_node`)

Failed merges:

r? @ghost
2019-01-19 15:52:58 +00:00
Mazdak Farrokhzad
92fecfbd60
Rollup merge of #57719 - nnethercote:expand_node-FIDDLING, r=nikomatsakis
Tweak `expand_node`

These commits speed up the `unicode_normalization` benchmark a little.
2019-01-19 14:21:24 +01:00
Mazdak Farrokhzad
e78bde4015
Rollup merge of #57699 - euclio:applicability-ify, r=petrochenkov
add applicability to remaining suggestions

Fixes #50723.

I noticed that the suggestion methods on `DiagnosticBuilder` weren't actually deprecated due to #57679. This PR deprecates them properly and fixes the remaining usages.

There's also a PR for clippy at rust-lang/rust-clippy#3667.
2019-01-19 14:21:23 +01:00
Mazdak Farrokhzad
c8c03afa57
Rollup merge of #57659 - jethrogb:jb/release-manifest, r=alexcrichton
Fix release manifest generation

r? @alexcrichton
2019-01-19 14:21:22 +01:00
Mazdak Farrokhzad
4eeb095437
Rollup merge of #57649 - petrochenkov:privexist, r=arielb1
privacy: Account for associated existential types

Turns out they *can* be associated (but only in impls, not traits).
Fixes https://github.com/rust-lang/rust/issues/53546#issuecomment-454372879

r? @arielb1
2019-01-19 14:21:21 +01:00
Mazdak Farrokhzad
bce56888e9
Rollup merge of #57598 - h-michael:unpretty-help, r=oli-obk
Add missing unpretty option help message

There are some missing help messages that is printed `ructc -Zunpretty help` and receiving invalid option.

related with #16419, #45721, #21085, #31916
2019-01-19 14:21:19 +01:00
Mazdak Farrokhzad
5272be5b5e
Rollup merge of #57502 - nikomatsakis:fix-trait-alias-1b, r=nikomatsakis
make trait-aliases work across crates

This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.

The stylistic edits I also rebased and can open a separate PR.

The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.

Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.

Fixes #56488.
Fixes #57023.
2019-01-19 14:21:18 +01:00
Mazdak Farrokhzad
349c9eeb35
Rollup merge of #57486 - nnethercote:simplify-TokenStream-more, r=petrochenkov
Simplify `TokenStream` some more

These commits simplify `TokenStream`, remove `ThinTokenStream`, and avoid some clones. The end result is simpler code and a slight perf win on some benchmarks.

r? @petrochenkov
2019-01-19 14:21:17 +01:00
bors
286ac62939 Auto merge of #57370 - petrhosek:llvm-flags, r=alexcrichton
Support passing cflags/cxxflags/ldflags to LLVM build

This may be needed with some host compilers.
2019-01-19 13:11:53 +00:00
bors
c87144f3ca Auto merge of #57752 - Centril:rollup, r=Centril
Rollup of 10 pull requests

Successful merges:

 - #57268 (Add a target option "merge-functions", and a corresponding -Z flag (works around #57356))
 - #57476 (Move glob map use to query and get rid of CrateAnalysis)
 - #57501 (High priority resolutions for associated variants)
 - #57573 (Querify `entry_fn`)
 - #57610 (Fix nested `?` matchers)
 - #57634 (Remove an unused function argument)
 - #57653 (Make the contribution doc reference the guide more)
 - #57666 (Generalize `huge-enum.rs` test and expected stderr for more cross platform cases)
 - #57698 (Fix typo bug in DepGraph::try_mark_green().)
 - #57746 (Update README.md)

Failed merges:

r? @ghost
2019-01-19 10:27:59 +00:00
Mazdak Farrokhzad
f7b9084e6e
Rollup merge of #57746 - mark-i-m:patch-2, r=Centril
Update README.md

Point contributors to the rustc-guide...

r? @steveklabnik
2019-01-19 09:03:34 +01:00
Mazdak Farrokhzad
c7686b787f
Rollup merge of #57698 - michaelwoerister:issue57692, r=Zoxc
Fix typo bug in DepGraph::try_mark_green().

r? @Zoxc

Fixes #57692.
2019-01-19 09:03:33 +01:00
Mazdak Farrokhzad
83921c31b8
Rollup merge of #57666 - pnkfelix:generalize-huge-enum-test-to-work-cross-platform, r=nikomatsakis
Generalize `huge-enum.rs` test and expected stderr for more cross platform cases

With this change, I am able to build and test cross-platform `rustc`

In particular, I can use the following in my `config.toml`:

```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```

Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.

----

To be concrete, here are the actual messages one can observe:

```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused  --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture

error: aborting due to previous error

% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused  --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture

error: aborting due to previous error

% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused  --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture

error: aborting due to previous error

% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused  --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture

error: aborting due to previous error
```

To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
2019-01-19 09:03:32 +01:00
Mazdak Farrokhzad
36a34e3dda
Rollup merge of #57653 - mark-i-m:contrib-doc, r=nikomatsakis
Make the contribution doc reference the guide more

and also remove a lot of redundant info already in the guide
2019-01-19 09:03:31 +01:00
Mazdak Farrokhzad
e00932a38d
Rollup merge of #57634 - oli-obk:remove_unused_argument, r=davidtwco
Remove an unused function argument

The only use was a debug printing, which might help someone with debugging dataflow problems, but seems otherwise useless
2019-01-19 09:03:29 +01:00
Mazdak Farrokhzad
fd779d3f76
Rollup merge of #57610 - mark-i-m:nested-matchers, r=petrochenkov
Fix nested `?` matchers

fix #57597

I'm not 100% if this works yet...

cc @alercah

When  this is ready (but perhaps not yet):
2019-01-19 09:03:28 +01:00
Mazdak Farrokhzad
64eb69b904
Rollup merge of #57573 - Xanewok:querify-entry-fn, r=Zoxc
Querify `entry_fn`

Analogous to https://github.com/rust-lang/rust/pull/57570 but this will also require few fixups in Miri so I decided to separate that (and it seems [CI doesn't let us break tools anymore](https://github.com/rust-lang/rust/pull/57392#issuecomment-453801540)? Or was that because it was a rollup PR?)

r? @nikomatsakis
2019-01-19 09:03:27 +01:00
Mazdak Farrokhzad
b941f290ac
Rollup merge of #57501 - petrochenkov:highvar, r=alexreg
High priority resolutions for associated variants

In https://github.com/rust-lang/rust/pull/56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.

This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.

Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if https://github.com/rust-lang/rfcs/pull/2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
2019-01-19 09:03:26 +01:00
Mazdak Farrokhzad
c0ad9429ab
Rollup merge of #57476 - Xanewok:bye-crate-analysis, r=Zoxc
Move glob map use to query and get rid of CrateAnalysis

~Also includes commits from ~https://github.com/rust-lang/rust/pull/57392~ and ~https://github.com/rust-lang/rust/pull/57436~.~

With glob map calculated unconditionally in https://github.com/rust-lang/rust/pull/57392, this PR moves the calculated glob map to `GlobalCtxt` and exposes a relevant query (as we do with other queries which copy precomputed data over from the `Resolver`).

This allows us to get rid of the `CrateAnalysis` struct in an attempt to simplify the compiler interface.
cc @Zoxc

r? @nikomatsakis @Zoxc @petrochenkov
2019-01-19 09:03:24 +01:00
Mazdak Farrokhzad
1dc54b7319
Rollup merge of #57268 - peterhj:peterhj-optmergefunc, r=nagisa
Add a target option "merge-functions", and a corresponding -Z flag (works around #57356)

This commit adds a target option "merge-functions", which takes values in ("disabled", "trampolines", or "aliases" (default is "aliases")), to allow targets to opt out of the MergeFunctions LLVM pass. Additionally, the latest commit also adds an optional -Z flag, "merge-functions", which takes the same values and has precedence over the target option when both are specified.

This works around https://github.com/rust-lang/rust/issues/57356.

cc @eddyb @japaric @oli-obk @nox @nagisa

Also thanks to @denzp and @gnzlbg for discussing this on rust-cuda!

### Motivation

Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3 [1], and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler `ptxas`). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does.

### Related work

The current behavior of rustc is to enable MergeFunctions at -O2 and -O3 [1], and also to enable the use of function aliases within MergeFunctions [2] [3]. MergeFunctions seems to have some benefits, such as reducing code size and fixing a crash [4], which is why it is enabled. However, MergeFunctions both with and without function aliases is incompatible with the NVPTX target; a more detailed example for both cases is given below.

clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.

### Examples/more details

Consider an example Rust lib using `extern "ptx-kernel"` functions: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore.rs. If we try to compile this with nightly rustc, we get the following compiler error:

    LLVM ERROR: Module has aliases, which NVPTX does not support.

This error happens because: (1) functions `foo` and `bar` have the same body, so are candidates to be merged by MergeFunctions; and (2) rustc configures MergeFunctions to generate function aliases using the "mergefunc-use-aliases" LLVM option [2] [3], but the NVPTX backend does not support those aliases.

Okay, so we can try omitting "mergefunc-use-aliases", and then rustc will happily emit PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-mergefunc-nousealiases-bad.ptx. However, this PTX is invalid! When we try to assemble it with `ptxas` (I'm on the CUDA 9.2 toolchain), we get an assembler error:

    ptxas nocore-mergefunc-nousealiases-bad.ptx, line 38; error   : Illegal call target, device function expected
    ptxas fatal   : Ptx assembly aborted due to errors

What's happening is that MergeFunctions rewrites the `bar` function to call `foo`. However, directly calling an `extern "ptx-kernel"` function from another `extern "ptx-kernel"` is wrong.

If we disable the MergeFunctions pass from running at all, rustc generates correct PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-nomergefunc-ok.ptx

[1] a36b960df6/src/librustc_codegen_ssa/back/write.rs (L155)
[2] a36b960df6/src/librustc_codegen_llvm/llvm_util.rs (L64)
[3] https://github.com/rust-lang/rust/pull/56358
[4] https://github.com/rust-lang/rust/pull/49479
2019-01-19 09:03:23 +01:00
bors
1bc6baec76 Auto merge of #57253 - Zoxc:incr-passes2, r=michaelwoerister
Make privacy checking, intrinsic checking and liveness checking incremental

Blocked on https://github.com/rust-lang/rust/pull/51487

r? @michaelwoerister
2019-01-19 07:42:43 +00:00
bors
af73e64423 Auto merge of #56722 - Aaron1011:fix/blanket-eval-overflow, r=nikomatsakis
Fix stack overflow when finding blanket impls

Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.

To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.

Fixes #56701

I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
2019-01-19 05:05:48 +00:00
bors
53b622a48a Auto merge of #56479 - mark-i-m:unsat, r=nikomatsakis
Better lifetime error message

I propose the following error message as more user-friendly

r? @nikomatsakis
2019-01-19 02:25:38 +00:00
bors
f001287c90 Auto merge of #57747 - Centril:rollup, r=Centril
Rollup of 11 pull requests

Successful merges:

 - #57107 (Add a regression test for mutating a non-mut #[thread_local])
 - #57132 (Document that `-C opt-level=0` implies `-C debug-assertions`.)
 - #57212 (docs(rustc): Link to the book's source in rustc)
 - #57302 (Fix unused_assignments false positive)
 - #57350 (Better error note on unimplemented Index trait for string)
 - #57635 (use structured macro and path resolve suggestions)
 - #57650 (librustc_metadata: Pass a default value when unwrapping a span)
 - #57657 (Add regression test to close #53787)
 - #57658 (Two HIR tweaks)
 - #57720 (Fix suggestions given mulitple bad lifetimes)
 - #57725 (Use structured suggestion to surround struct literal with parenthesis)

Failed merges:

r? @ghost
2019-01-18 23:40:14 +00:00
Mazdak Farrokhzad
2a830e47e1
Rollup merge of #57725 - estebank:parens, r=michaelwoerister
Use structured suggestion to surround struct literal with parenthesis
2019-01-18 22:56:48 +01:00
Mazdak Farrokhzad
42accf06dc
Rollup merge of #57720 - dlrobertson:fix_57521, r=estebank
Fix suggestions given mulitple bad lifetimes

When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.

r? @estebank

CC @pnkfelix

Fixes: #57521
2019-01-18 22:56:47 +01:00
Mazdak Farrokhzad
857d27fb14
Rollup merge of #57658 - nnethercote:rm-hir-P-Lit, r=michaelwoerister
Two HIR tweaks

Two HIR tweaks that make things slightly simpler and faster.
2019-01-18 22:56:45 +01:00
Mazdak Farrokhzad
0eb4bdc5f1
Rollup merge of #57657 - AB1908:regression-test-case, r=nikomatsakis
Add regression test to close #53787

Fixes #53787
2019-01-18 22:56:44 +01:00
Mazdak Farrokhzad
d2300afd66
Rollup merge of #57650 - AB1908:master, r=petrochenkov
librustc_metadata: Pass a default value when unwrapping a span

Fixes #57323.

When compiling with `static-nobundle` a-la

`rustc -l static-nobundle=nonexistent main.rs`

we now get a neat output in the form of:

```
error[E0658]: kind="static-nobundle" is feature gated (see issue #37403)
  |
  = help: add #![feature(static_nobundle)] to the crate attributes to enable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?
2019-01-18 22:56:43 +01:00
Mazdak Farrokhzad
f63e3d2ef4
Rollup merge of #57635 - euclio:path-separators, r=michaelwoerister
use structured macro and path resolve suggestions
2019-01-18 22:56:42 +01:00