1488 Commits

Author SHA1 Message Date
Yuki Okushi
7b4c397b73 Do not try to report on closures to avoid ICE 2020-10-25 11:19:49 +09:00
bors
f58ffc9381 Auto merge of #78334 - jonas-schievink:rollup-z0gzbmm, r=jonas-schievink
Rollup of 12 pull requests

Successful merges:

 - #75115 (`#[deny(unsafe_op_in_unsafe_fn)]` in sys/cloudabi)
 - #76614 (change the order of type arguments on ControlFlow)
 - #77610 (revise Hermit's mutex interface to support the behaviour of StaticMutex)
 - #77830 (Simplify query proc-macros)
 - #77930 (Do not ICE with TraitPredicates containing [type error])
 - #78069 (Fix const core::panic!(non_literal_str).)
 - #78072 (Cleanup constant matching in exhaustiveness checking)
 - #78119 (Throw core::panic!("message") as &str instead of String.)
 - #78191 (Introduce a temporary for discriminant value in MatchBranchSimplification)
 - #78272 (const_evaluatable_checked: deal with unused nodes + div)
 - #78318 (TyCtxt: generate single impl block with `slice_interners` macro)
 - #78327 (resolve: Relax macro resolution consistency check to account for any errors)

Failed merges:

r? `@ghost`
2020-10-24 21:42:39 +00:00
Jonas Schievink
58ae889779
Rollup merge of #78327 - petrochenkov:inconsist, r=Aaron1011
resolve: Relax macro resolution consistency check to account for any errors

The check was previously omitted only when ambiguity errors or `Res::Err` were encountered, but the "macro-expanded `extern crate` items cannot shadow..." error (at least) can cause same inconsistencies as well.

Fixes https://github.com/rust-lang/rust/issues/78325
2020-10-24 22:40:00 +02:00
Jonas Schievink
a8ff5a4e03
Rollup merge of #78318 - bugadani:tyctx-impl, r=petrochenkov
TyCtxt: generate single impl block with `slice_interners` macro

Reduces the work needed to check overlapping impls a bit.
2020-10-24 22:39:59 +02:00
Jonas Schievink
5ed8ac45d4
Rollup merge of #78272 - lcnr:abstract-const-unused-node, r=oli-obk
const_evaluatable_checked: deal with unused nodes + div

r? @oli-obk
2020-10-24 22:39:57 +02:00
Jonas Schievink
597b4c5bb4
Rollup merge of #78191 - tmiasko:temp-match-branch-simplification, r=oli-obk
Introduce a temporary for discriminant value in MatchBranchSimplification

The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.

Evaluate it once at original position, and store the result in a new temporary.

Follow up on #78151. The optimization remains disabled by default.

Closes #78239.
2020-10-24 22:39:55 +02:00
Jonas Schievink
e12e97223f
Rollup merge of #78072 - Nadrieril:cleanup-constant-matching, r=varkor
Cleanup constant matching in exhaustiveness checking

This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work.
I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately.

I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior.

EDIT: I accidentally fixed #78071
2020-10-24 22:39:51 +02:00
Jonas Schievink
0a06d7344b
Rollup merge of #78069 - fusion-engineering-forks:core-const-panic-str, r=RalfJung
Fix const core::panic!(non_literal_str).

Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.

This fixes the issue mentioned here: https://github.com/rust-lang/rust/issues/51999#issuecomment-687604248

r? `@RalfJung`

`@rustbot` modify labels: +A-const-eval
2020-10-24 22:39:49 +02:00
Jonas Schievink
7428de1583
Rollup merge of #77930 - estebank:ice-77919, r=eddyb
Do not ICE with TraitPredicates containing [type error]

Fix #77919.
2020-10-24 22:39:47 +02:00
Jonas Schievink
4d72939af1
Rollup merge of #77830 - cjgillot:remacro, r=oli-obk
Simplify query proc-macros

The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`.

This PR removes unused capabilities of the proc-macros, and tend to use regular macros for the logic.
2020-10-24 22:39:46 +02:00
Jonas Schievink
a547055184
Rollup merge of #76614 - NoraCodes:nora/control_flow_enum, r=scottmcm
change the order of type arguments on ControlFlow

This allows ControlFlow<BreakType> which is much more ergonomic for common iterator combinator use cases.

Addresses one component of #75744
2020-10-24 22:39:41 +02:00
Wesley Wiser
dd683e5ab5 MIR validation should check SwitchInt values are valid for the type 2020-10-24 16:00:04 -04:00
bors
ffa2e7ae8f Auto merge of #77255 - Aaron1011:feature/collect-attr-tokens, r=petrochenkov
Unconditionally capture tokens for attributes.

This allows us to avoid synthesizing tokens in `prepend_attr`, since we
have the original tokens available.

We still need to synthesize tokens when expanding `cfg_attr`,
but this is an unavoidable consequence of the syntax of `cfg_attr` -
the user does not supply the `#` and `[]` tokens that a `cfg_attr`
expands to.

This is based on PR https://github.com/rust-lang/rust/pull/77250 - this PR exposes a bug in the current `collect_tokens` implementation, which is fixed by the rewrite.
2020-10-24 19:23:32 +00:00
Ralf Jung
5d624929cf
fix typo
Co-authored-by: BlackHoleFox <blackholefoxdev@gmail.com>
2020-10-24 20:39:04 +02:00
Aaron Hill
283053a742
Compute proper module parent during resolution
Fixes #75982

The direct parent of a module may not be a module
(e.g. `const _: () =  { #[path = "foo.rs"] mod foo; };`).

To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.
2020-10-24 14:28:13 -04:00
Vadim Petrochenkov
ef09ed2002 resolve: Relax macro resolution consistency check to account for any errors 2020-10-24 21:26:08 +03:00
Jake Goulding
c6ab758e54 Switch from tuple matching to match guards 2020-10-24 12:58:38 -04:00
Aaron Hill
ac384ac2db
Fix inconsistencies in handling of inert attributes on statements
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-24 11:55:48 -04:00
Ralf Jung
1333206eb3 ensure that statics are inhabited 2020-10-24 16:15:42 +02:00
Jonas Schievink
1ac137be93
Rollup merge of #78307 - rust-lang:revert-77961-embed-bitcode, r=tmandry
Revert "Set .llvmbc and .llvmcmd sections as allocatable"

Reverts rust-lang/rust#77961, see discussion starting from https://github.com/rust-lang/rust/pull/77961#issuecomment-712313902
2020-10-24 14:12:20 +02:00
Jonas Schievink
da486467d4
Rollup merge of #78300 - richkadel:coverage-cx, r=wesleywiser
Make codegen coverage_context optional, and check

Addresses Issue #78286

Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).

Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.
2020-10-24 14:12:18 +02:00
Jonas Schievink
2362659b00
Rollup merge of #78292 - bugadani:recursion, r=nagisa
Loop instead of recursion

I saw the comment `// FIXME: consider not using recursion to lower this.` and considered not using recursion :)
2020-10-24 14:12:15 +02:00
Jonas Schievink
b6ae1fabee
Rollup merge of #78278 - lcnr:predicate-visit, r=matthewjasper
move `visit_predicate` into `TypeVisitor`

Seems easier than dealing with `PredicateVisitor` for me which I needed for object safety checks for `PredicateAtom::ConstEvaluatable`. Is there a reason I am missing for this split?

r? @matthewjasper
2020-10-24 14:12:13 +02:00
Jonas Schievink
77cd5b5485
Rollup merge of #78249 - lcnr:ct-infer-origin, r=varkor
improve const infer error

For type inference we probably have to be careful about subtyping and stuff but considering that subtyping shouldn't be relevant for constants I don't really see a reason why we may not want to reuse the const origin here.

r? `@varkor`
2020-10-24 14:12:06 +02:00
Jonas Schievink
86c07a4955
Rollup merge of #78198 - tmiasko:assert, r=davidtwco
Simplify assert terminator only if condition evaluates to expected value
2020-10-24 14:12:03 +02:00
Jonas Schievink
fb92b70f95
Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking, r=jonas-schievink
Revert "Allow dynamic linking for iOS/tvOS targets."

This reverts PR #73516.

On macOS I compile static libs for iOS, automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile), which has worked smoothly for the past 2 years. However, upon updating to Rust 1.46.0, I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above.

For most projects tested, apps now immediately crash with a message like this:
```
dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib
  Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example
  Reason: image not found
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib
```

This can be reproduced by using cargo-mobile to generate a winit example project, and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`).

In our projects that depend on DisplayLink, the build instead fails with a linker error:
```
= note: Undefined symbols for architecture arm64:
            "_CACurrentMediaTime", referenced from:
                display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
                display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
          ld: symbol(s) not found for architecture arm64
```

After reverting the change to enable dynamic linking on iOS, everything works the same as it did on Rust 1.45.2 for me.

In the future, would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production, so I'd gladly provide testing.

cc @aspenluxxxy
2020-10-24 14:11:59 +02:00
Dániel Buga
6533d010cf Don't generate multiple impl blocks 2020-10-24 11:55:00 +02:00
Dániel Buga
f88d6e8437 Loop instead of recursion 2020-10-24 01:24:58 +02:00
Rich Kadel
f75a236fe0
Update compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rs
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
2020-10-23 14:58:08 -07:00
Tyler Mandry
6640a62e0e
Revert "Set .llvmbc and .llvmcmd sections as allocatable" 2020-10-23 12:54:00 -07:00
Esteban Küber
f71e9ed7f1 review comments 2020-10-23 12:51:06 -07:00
Esteban Küber
b334eef162 Do not ICE with TraitPredicates containing [type error]
Fix #77919.
2020-10-23 12:21:47 -07:00
Rich Kadel
a7bc1a2edf Make codegen coverage_context optional, and check
Addresses Issue #78286

Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).

Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.
2020-10-23 12:00:30 -07:00
bors
7bade6ef73 Auto merge of #77015 - davidtwco:check-attr-variant-closure-expr, r=lcnr
passes: `check_attr` on more targets

This PR modifies `check_attr` so that:

- Enum variants are now checked (some attributes would not have been prohibited on variants previously).
- `check_expr_attributes` and `check_stmt_attributes` are removed as `check_attributes` can perform the same checks. This means that codegen attribute errors aren't shown if there are other errors first (e.g. from other attributes, as shown in `src/test/ui/macros/issue-68060.rs` changes below).
2020-10-23 17:32:04 +00:00
Florian Warzecha
ac2c599f23
fix validation for rustc_allow_const_fn_unstable targets
The validation was introduced in 3a63bf02998f7b5e040a4b87e049d03ddd144f74
without strict validation of functions, e. g. all function types were
allowed.
Now the validation only allows `const fn`s.
2020-10-23 17:54:48 +02:00
Florian Warzecha
13b481b247
rename allow_internal_unstable() to rustc_allow_const_fn_unstable() in rustc_mir
Followup rename from 05f4a9a42abbbdb64d3ec4ed0ae6883c10c66e3f,
which introduced `#[rustc_allow_const_fn_unstable]` for `const fn`s.
2020-10-23 17:14:57 +02:00
Esteban Küber
f5d7443a6b Suggest semicolon removal and boxing when appropriate 2020-10-23 08:06:41 -07:00
Esteban Küber
c5485115dc Add more .await suggestions on E0308 2020-10-23 08:06:41 -07:00
Esteban Küber
3a0227bc49 Silence unnecessary await foo? knock-down error 2020-10-23 08:06:41 -07:00
Esteban Küber
62ba365195 Review comments: use newtype instead of bool 2020-10-23 08:06:41 -07:00
Esteban Küber
671d7c4afb Account for possible boxable impl Future in semicolon removal suggestions 2020-10-23 08:06:13 -07:00
Esteban Küber
a4ee3ca1e4 Suggest semicolon removal on prior match arm 2020-10-23 08:02:58 -07:00
Esteban Küber
86df9039b2 Tweak "use .await" suggestion 2020-10-23 08:02:57 -07:00
Florian Warzecha
83fbdddc99
ignore #[rustc_allow_const_fn_unstable] for macro expansion
Recognition for `rustc_allow_const_fn_unstable` attribute was errorneously
added in 05f4a9a42abbbdb64d3ec4ed0ae6883c10c66e3f.
2020-10-23 16:54:25 +02:00
Bastian Kauschke
47cb871f14 review 2020-10-23 15:04:12 +02:00
Bastian Kauschke
972d9e886c move visit_predicate into TypeVisitor 2020-10-23 13:58:32 +02:00
Bastian Kauschke
6ad140ca19 const_eval_checked: deal with unused nodes + div 2020-10-23 12:16:58 +02:00
Yuki Okushi
7ba519ec50
Rollup merge of #78255 - dtolnay:match, r=lcnr
Reduce diagram mess in 'match arms have incompatible types' error

I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span.

This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline.

**Before:**

<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
   <b>--&gt;</b> src/topology/builder.rs:141:35
    <b>|</b>
<b>120 |</b>             let transform = match transform {
    <b>|    _________________________-</b>
<b>121 |   |</b>             Transform::Function(t) =&gt; {
    <b>|  _|_______________________________________-</b>
<b>122 | | |</b>                 filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | | |</b>                     futures::stream::iter(match v {
<b>124 | | |</b>                         Err(e) =&gt; {
<b>...   | |</b>
<b>139 | | |</b>                 .compat();
<b>140 | | |</b>             }
    <b>| |_|_____________- this is found to be of type `()`</b>
<b>141 |   |</b>             Transform::Task(t) =&gt; t
    <b>|  _|___________________________________^</b>
<b>142 | | |</b>                 .transform(filter_event_type(input_rx, input_type))
<b>143 | | |</b>                 .forward(output)
<b>144 | | |</b>                 .map(|_| debug!("Finished"))
<b>145 | | |</b>                 .compat(),
    <b>| |_|_________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>146 |   |</b>         };
    <b>|   |_________- `match` arms have incompatible types</b>
    <b>|</b>
    <b>= note:</b> expected type `<b>()</b>`
             found struct `<b>futures::compat::Compat01As03&lt;futures::Map&lt;futures::stream::Forward&lt;std::boxed::Box&lt;dyn futures::Stream&lt;Error = (), Item = event::Event&gt; + std::marker::Send&gt;, topology::fanout::Fanout&gt;, [closure@src/topology/builder.rs:144:22: 144:44]&gt;&gt;</b>`
</pre>

**After:**

<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
   <b>--&gt;</b> src/topology/builder.rs:141:35
    <b>|</b>
<b>120 |</b>             let transform = match transform {
    <b>|                             --------------- `match` arms have incompatible types</b>
<b>121 |</b>                 Transform::Function(t) =&gt; {
    <b>|  _________________________________________-</b>
<b>122 | |</b>                   filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | |</b>                       futures::stream::iter(match v {
<b>124 | |</b>                           Err(e) =&gt; {
<b>...   |</b>
<b>139 | |</b>                   .compat();
<b>140 | |</b>               }
    <b>| |_______________- this is found to be of type `()`</b>
<b>141 |</b>                 Transform::Task(t) =&gt; t
    <b>|  _____________________________________^</b>
<b>142 | |</b>                   .transform(filter_event_type(input_rx, input_type))
<b>143 | |</b>                   .forward(output)
<b>144 | |</b>                   .map(|_| debug!("Finished"))
<b>145 | |</b>                   .compat(),
    <b>| |___________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
    <b>|</b>
    <b>= note:</b> expected type `<b>()</b>`
             found struct `<b>futures::compat::Compat01As03&lt;futures::Map&lt;futures::stream::Forward&lt;std::boxed::Box&lt;dyn futures::Stream&lt;Error = (), Item = event::Event&gt; + std::marker::Send&gt;, topology::fanout::Fanout&gt;, [closure@src/topology/builder.rs:144:22: 144:44]&gt;&gt;</b>`
</pre>

FYI @Hoverbear
2020-10-23 18:26:40 +09:00
Yuki Okushi
3f462c22b5
Rollup merge of #78235 - Aaron1011:closure-ret-infer, r=varkor
Explain where the closure return type was inferred

Fixes #78193
2020-10-23 18:26:39 +09:00
Yuki Okushi
00c4dcdbb4
Rollup merge of #78231 - LeSeulArtichaut:closure-target_feature, r=nikomatsakis
Make closures inherit the parent function's target features

r? @ghost
Closes #73631
2020-10-23 18:26:37 +09:00