Commit Graph

165 Commits

Author SHA1 Message Date
est31 0d1aa1e034 Rename target_pointer_width to pointer_width and turn it into an u32
Rename target_pointer_width to pointer_width because it is already
member of the Target struct.

The compiler supports only three valid values for target_pointer_width:
16, 32, 64. Thus it can safely be turned into an int.
This means less allocations and clones as well as easier handling of the type.
2020-10-15 12:02:23 +02:00
Arlo Siemsen 3296d5ca7b Add support for SHA256 source file hashing for LLVM 11+. 2020-10-14 15:09:51 -07:00
est31 215cd36e1c Remove unused code from remaining compiler crates 2020-10-14 04:14:32 +02:00
bors f54072bb81 Auto merge of #76830 - Artoria2e5:tune, r=nagisa
Pass tune-cpu to LLVM

I think this is how it should work...

See https://internals.rust-lang.org/t/expose-tune-cpu-from-llvm/13088 for the background. Or the documentation diff.
2020-10-13 02:49:00 +00:00
bors 8ae3b50976 Auto merge of #77119 - GuillaumeGomez:unclosed-html-tag-lint, r=jyn514
Unclosed html tag lint

Part of #67799.

I think `@ollie27` will be interested (`@Manishearth` too since they opened the issue ;) ).

r? `@jyn514`
2020-10-07 09:56:51 +00:00
Rich Kadel f5aebad28f Updates to experimental coverage counter injection
This is a combination of 18 commits.

Commit #2:

Additional examples and some small improvements.

Commit #3:

fixed mir-opt non-mir extensions and spanview title elements

Corrected a fairly recent assumption in runtest.rs that all MIR dump
files end in .mir. (It was appending .mir to the graphviz .dot and
spanview .html file names when generating blessed output files. That
also left outdated files in the baseline alongside the files with the
incorrect names, which I've now removed.)

Updated spanview HTML title elements to match their content, replacing a
hardcoded and incorrect name that was left in accidentally when
originally submitted.

Commit #4:

added more test examples

also improved Makefiles with support for non-zero exit status and to
force validation of tests unless a specific test overrides it with a
specific comment.

Commit #5:

Fixed rare issues after testing on real-world crate

Commit #6:

Addressed PR feedback, and removed temporary -Zexperimental-coverage

-Zinstrument-coverage once again supports the latest capabilities of
LLVM instrprof coverage instrumentation.

Also fixed a bug in spanview.

Commit #7:

Fix closure handling, add tests for closures and inner items

And cleaned up other tests for consistency, and to make it more clear
where spans start/end by breaking up lines.

Commit #8:

renamed "typical" test results "expected"

Now that the `llvm-cov show` tests are improved to normally expect
matching actuals, and to allow individual tests to override that
expectation.

Commit #9:

test coverage of inline generic struct function

Commit #10:

Addressed review feedback

* Removed unnecessary Unreachable filter.
* Replaced a match wildcard with remining variants.
* Added more comments to help clarify the role of successors() in the
CFG traversal

Commit #11:

refactoring based on feedback

* refactored `fn coverage_spans()`.
* changed the way I expand an empty coverage span to improve performance
* fixed a typo that I had accidently left in, in visit.rs

Commit #12:

Optimized use of SourceMap and SourceFile

Commit #13:

Fixed a regression, and synched with upstream

Some generated test file names changed due to some new change upstream.

Commit #14:

Stripping out crate disambiguators from demangled names

These can vary depending on the test platform.

Commit #15:

Ignore llvm-cov show diff on test with generics, expand IO error message

Tests with generics produce llvm-cov show results with demangled names
that can include an unstable "crate disambiguator" (hex value). The
value changes when run in the Rust CI Windows environment. I added a sed
filter to strip them out (in a prior commit), but sed also appears to
fail in the same environment. Until I can figure out a workaround, I'm
just going to ignore this specific test result. I added a FIXME to
follow up later, but it's not that critical.

I also saw an error with Windows GNU, but the IO error did not
specify a path for the directory or file that triggered the error. I
updated the error messages to provide more info for next, time but also
noticed some other tests with similar steps did not fail. Looks
spurious.

Commit #16:

Modify rust-demangler to strip disambiguators by default

Commit #17:

Remove std::process::exit from coverage tests

Due to Issue #77553, programs that call std::process::exit() do not
generate coverage results on Windows MSVC.

Commit #18:

fix: test file paths exceeding Windows max path len
2020-10-05 08:02:58 -07:00
Mingye Wang a35a93f09c Pass tune-cpu to LLVM
I think this is how it should work...
2020-10-05 07:50:44 +08:00
Guillaume Gomez 3641a37455 Enforce crate level attributes checks 2020-10-04 13:36:47 +02:00
Guillaume Gomez f9a65afb27 Make invalid_html_tags lint only run on nightly and being allowed by default 2020-10-03 14:16:24 +02:00
Guillaume Gomez e6027a42e1 Add `unclosed_html_tags` lint 2020-10-03 14:16:23 +02:00
Dylan MacKenzie 6691d11234 Add `-Zprecise-enum-drop-elaboration`
Its purpose is to assist in debugging #77382 and #74551.
2020-10-01 11:31:43 -07:00
Wesley Wiser b9d0ea95c8 [mir-opt] Introduce a new flag to enable experimental/unsound mir opts 2020-09-27 19:21:01 -04:00
Jonas Schievink 65298ee49c
Rollup merge of #77262 - bugadani:redundant-comment, r=Dylan-DPC
Remove duplicate comment
2020-09-27 18:37:28 +02:00
Joshua Nelson 80ffaed809 Add documentation for `private_intra_doc_links` 2020-09-27 10:44:41 -04:00
Joshua Nelson 03d8be0896 Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints
This is not ideal because it means `deny(broken_intra_doc_links)` will
no longer `deny(private_intra_doc_links)`. However, it can't be fixed
with a new lint group, because `broken` is already in the `rustdoc` lint
group; there would need to be a way to nest groups somehow.

This also removes the early `return` so that the link will be generated
even though it gives a warning.
2020-09-27 09:58:29 -04:00
Dániel Buga 3d4a2e6bb9 Remove duplicate comment 2020-09-27 11:00:46 +02:00
Ralf Jung 9e02642fb3
Rollup merge of #77211 - est31:remove_unused_allow, r=oli-obk
Remove unused #[allow(...)] statements from compiler/
2020-09-26 12:58:34 +02:00
bors fd15e6180d Auto merge of #70743 - oli-obk:eager_const_to_pat_conversion, r=eddyb
Fully destructure constants into patterns

r? `@varkor`

as discussed in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/constants.20in.20patterns/near/192789924

we should probably crater it once reviewed
2020-09-26 06:44:28 +00:00
est31 12187b7f86 Remove unused #[allow(...)] statements from compiler/ 2020-09-26 01:25:55 +02:00
Oliver Scherer 2bc54d4273 Don't talk about determinism 2020-09-24 09:43:10 +02:00
Oliver Scherer 9aa1c0934c Update documentation tests 2020-09-23 18:55:27 +02:00
Mara Bos 9e3f94dabc Don't unwrap but report a fatal error for TargetDataLayout::parse. 2020-09-21 20:43:44 +02:00
Mara Bos db74e1f1e3 Add cfg(target_has_atomic_equal_alignment).
This is needed for Atomic::from_mut.
2020-09-21 20:42:25 +02:00
Oliver Scherer f12583a330 Pacify tidy 2020-09-21 16:38:29 +02:00
Oliver Scherer f7eceef653 Document future incompat lints 2020-09-21 14:27:14 +02:00
Oliver Scherer adf98ab2dc Use precise errors during const to pat conversion instead of a catch-all on the main constant 2020-09-20 18:42:15 +02:00
Oliver Scherer aba5ea1430 Lint on function pointers used in patterns 2020-09-20 18:42:15 +02:00
Ralf Jung c847eaa91d
Rollup merge of #76832 - khyperia:backend_target_override, r=eddyb
Let backends define custom targets

Add a target_override hook that takes priority over builtin targets.
2020-09-20 15:51:48 +02:00
khyperia c946c40d9d Let backends define custom targets
Add a target_override hook that takes priority over builtin targets.
2020-09-17 12:01:12 +02:00
Matthias Krüger 012974da7a use strip_prefix over starts_with and manual slicing based on pattern length (clippy::manual_strip) 2020-09-17 10:13:16 +02:00
Tyler Mandry 3bf66ae25f
Rollup merge of #76794 - richkadel:graphviz-font, r=ecstatic-morse
Make graphviz font configurable

Alternative to PR #76776.

To change the graphviz output to use an alternative `fontname` value,
add a command line option like: `rustc --graphviz-font=monospace`.

r? @ecstatic-morse
2020-09-16 12:24:30 -07:00
Rich Kadel 3875abe32f Added RUSTC_GRAPHVIZ_FONT environment variable
Overrides the debugging_opts.graphviz_font setting.
2020-09-16 11:27:17 -07:00
Rich Kadel 5c29332ace Make graphviz font configurable
Alternative to PR ##76776.

To change the graphviz output to use an alternative `fontname` value,
add a command line option like: `rustc --graphviz-font=monospace`.
2020-09-16 08:10:06 -07:00
Eric Huss 49a61f59df Make const_evaluatable_unchecked lint example not depend on the architecture pointer size. 2020-09-13 11:13:59 -07:00
Eric Huss c04973585d Support `ignore` for lint examples. 2020-09-13 08:48:03 -07:00
Eric Huss ce014be0b9 Link rustdoc lint docs to the rustdoc book. 2020-09-13 08:48:03 -07:00
Eric Huss 45c1e0ae07 Auto-generate lint documentation. 2020-09-13 08:48:03 -07:00
bors 989190874f Auto merge of #76538 - fusion-engineering-forks:check-useless-unstable-trait-impl, r=lcnr
Warn for #[unstable] on trait impls when it has no effect.

Earlier today I sent a PR with an `#[unstable]` attribute on a trait `impl`, but was informed that this attribute has no effect there. (comment: https://github.com/rust-lang/rust/pull/76525#issuecomment-689678895, issue: https://github.com/rust-lang/rust/issues/55436)

This PR adds a warning for this situation. Trait `impl` blocks with `#[unstable]` where both the type and the trait are stable will result in a warning:

```
warning: An `#[unstable]` annotation here has no effect. See issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information.
   --> library/std/src/panic.rs:235:1
    |
235 | #[unstable(feature = "integer_atomics", issue = "32976")]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

---

It detects three problems in the existing code:

1. A few `RefUnwindSafe` implementations for the atomic integer types in `library/std/src/panic.rs`. Example:
d92155bf6a/library/std/src/panic.rs (L235-L236)
2. An implementation of `Error` for `LayoutErr` in `library/std/srd/error.rs`:
d92155bf6a/library/std/src/error.rs (L392-L397)
3. `From` implementations for `Waker` and `RawWaker` in `library/alloc/src/task.rs`. Example:
d92155bf6a/library/alloc/src/task.rs (L36-L37)

Case 3 interesting: It has a bound with an `#[unstable]` trait (`W: Wake`), so appears to have much effect on stable code. It does however break similar blanket implementations. It would also have immediate effect if `Wake` was implemented for any stable type. (Which is not the case right now, but there are no warnings in place to prevent it.) Whether this case is a problem or not is not clear to me. If it isn't, adding a simple `c.visit_generics(..);` to this PR will stop the warning for this case.
2020-09-12 18:01:33 +00:00
Mara Bos 89fb34fea7 Turn unstable trait impl error into a lint, so it can be disabled. 2020-09-11 13:36:42 +02:00
Matthias Krüger 9bb10cc907 use push(char) instead of push_str(&str) to add single chars to strings
clippy::single-char-push-str
2020-09-10 13:58:41 +02:00
bors 88197214b8 Auto merge of #75573 - Aaron1011:feature/const-mutation-lint, r=oli-obk
Add CONST_ITEM_MUTATION lint

Fixes #74053
Fixes #55721

This PR adds a new lint `CONST_ITEM_MUTATION`.
Given an item `const FOO: SomeType = ..`, this lint fires on:

* Attempting to write directly to a field (`FOO.field = some_val`) or
  array entry (`FOO.array_field[0] = val`)
* Taking a mutable reference to the `const` item (`&mut FOO`), including
  through an autoderef `FOO.some_mut_self_method()`

The lint message explains that since each use of a constant creates a
new temporary, the original `const` item will not be modified.
2020-09-10 05:54:26 +00:00
Tyler Mandry ba6e2b3a31
Rollup merge of #76500 - richkadel:mir-graphviz-dark, r=tmandry
Add -Zgraphviz_dark_mode and monospace font fix

Many developers use a dark theme with editors and IDEs, but this
typically doesn't extend to graphviz output.

When I bring up a MIR graphviz document, the white background is
strikingly bright. This new option changes the colors used for graphviz
output to work better in dark-themed UIs.

<img width="1305" alt="Screen Shot 2020-09-09 at 3 00 31 PM" src="https://user-images.githubusercontent.com/3827298/92659478-4b9bff00-f2ad-11ea-8894-b40d3a873cb9.png">

Also fixed the monospace font for common graphviz renders (e.g., VS Code extensions), as described in https://github.com/rust-lang/rust/pull/76500#issuecomment-689837948

**Before:**
<img width="943" alt="Screen Shot 2020-09-09 at 2 48 44 PM" src="https://user-images.githubusercontent.com/3827298/92658939-47231680-f2ac-11ea-97ac-96727e4dd622.png">

**Now with fix:**
<img width="943" alt="Screen Shot 2020-09-09 at 2 49 02 PM" src="https://user-images.githubusercontent.com/3827298/92658959-51451500-f2ac-11ea-9aae-de982d466d6a.png">
2020-09-09 21:02:35 -07:00
Tyler Mandry 07dbe49ce9
Rollup merge of #75094 - 0dvictor:cgu, r=oli-obk
Add `-Z combine_cgu` flag

Introduce a compiler option to let rustc combines all regular CGUs into a single one at the end of compilation.

Part of Issue #64191
2020-09-09 15:05:43 -07:00
Victor Ding c81b43d8ac Add `-Z combine_cgu` flag
Introduce a compiler option to let rustc combines all regular CGUs into
a single one at the end of compilation.

Part of Issue #64191
2020-09-09 17:32:23 +10:00
Rich Kadel c19b2370e4 Add -Zgraphviz_dark_mode
Many developers use a dark theme with editors and IDEs, but this
typically doesn't extend to graphviz output.

When I bring up a MIR graphviz document, the white background is
strikingly bright. This new option changes the colors used for graphviz
output to work better in dark-themed UIs.
2020-09-08 17:19:38 -07:00
Bastian Kauschke 1dd00e60b9 add tracking issue, fix rebase 2020-09-08 16:39:12 +02:00
Bastian Kauschke ef6100e846 convert to future compat lint 2020-09-08 16:39:12 +02:00
bors 71569e4201 Auto merge of #75138 - jumbatm:session-diagnostic-derive, r=oli-obk
Add derive macro for specifying diagnostics using attributes.

Introduces `#[derive(SessionDiagnostic)]`, a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently, the following attributes have been implemented:
- `#[code = "..."]` -- this sets the Diagnostic's error code, and must be provided on the struct iself (ie, not on a field). Equivalent to calling `code`.
- `#[message = "..."]` -- this sets the Diagnostic's primary error message.
- `#[label = "..."]` -- this must be applied to fields of type `Span`, and is equivalent to `span_label`
- `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span, Applicability)`, and is equivalent to calling `span_suggestion`. Valid arguments are:
    - `message = "..."` -- this sets the suggestion message.
    - (Optional) `code = "..."` -- this suggests code for the suggestion. Defaults to empty.

`suggestion`also  comes with other variants: `#[suggestion_short(..)]`, `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys.

Within the strings passed to each attribute, fields can be referenced without needing to be passed explicitly into the format string -- eg, `#[error = "{ident} already declared"] ` will set the error message to `format!("{} already declared", &self.ident)`. Any fields on the struct can be referenced in this way.

Additionally, for any of these attributes, Option fields can be used to only optionally apply the decoration -- for example:

```rust
#[derive(SessionDiagnostic)]
#[code = "E0123"]
struct SomeKindOfError {
    ...
    #[suggestion(message = "informative error message")]
    opt_sugg: Option<(Span, Applicability)>
    ...
}
```
will not emit a suggestion if `opt_sugg` is `None`.

We plan on iterating on this macro further; this PR is a start.

Closes #61132.

r? `@oli-obk`
2020-09-08 00:58:43 +00:00
Aaron Hill f422ef141a
Add CONST_ITEM_MUTATION lint
Fixes #74053
Fixes #55721

This PR adds a new lint `CONST_ITEM_MUTATION`.
Given an item `const FOO: SomeType = ..`, this lint fires on:

* Attempting to write directly to a field (`FOO.field = some_val`) or
  array entry (`FOO.array_field[0] = val`)
* Taking a mutable reference to the `const` item (`&mut FOO`), including
  through an autoderef `FOO.some_mut_self_method()`

The lint message explains that since each use of a constant creates a
new temporary, the original `const` item will not be modified.
2020-09-07 08:44:35 -04:00
bors 4ffb5c5954 Auto merge of #76004 - richkadel:llvm-coverage-map-gen-6b.5, r=tmandry
Tools, tests, and experimenting with MIR-derived coverage counters

Leverages the new mir_dump output file in HTML+CSS (from #76074) to visualize coverage code regions
and the MIR features that they came from (including overlapping spans).

See example below.

The `run-make-fulldeps/instrument-coverage` test has been refactored to maximize test coverage and reduce code duplication. The new tests support testing with and without `-Clink-dead-code`, so Rust coverage can be tested on MSVC (which, currently, only works with `link-dead-code` _disabled_).

New tests validate coverage region generation and coverage reports with multiple counters per function. Starting with a simple `if-else` branch tests, coverage tests for each additional syntax type can be added by simply dropping in a new Rust sample program.

Includes a basic, MIR-block-based implementation of coverage injection,
available via `-Zexperimental-coverage`. This implementation has known
flaws and omissions, but is simple enough to validate the new tools and
tests.

The existing `-Zinstrument-coverage` option currently enables
function-level coverage only, which at least appears to generate
accurate coverage reports at that level.

Experimental coverage is not accurate at this time. When branch coverage
works as intended, the `-Zexperimental-coverage` option should be
removed.

This PR replaces the bulk of PR #75828, with the remaining parts of
that PR distributed among other separate and indentpent PRs.

This PR depends on two of those other PRs: #76002, #76003 and #76074

Rust compiler MCP rust-lang/compiler-team#278

Relevant issue: #34701 - Implement support for LLVMs code coverage
instrumentation

![Screen-Recording-2020-08-21-at-2](https://user-images.githubusercontent.com/3827298/90972923-ff417880-e4d1-11ea-92bb-8713c6198f6d.gif)

r? @tmandry
FYI: @wesleywiser
2020-09-04 01:31:07 +00:00
Rich Kadel 51d692cf77 Tools, tests, and experimenting with MIR-derived coverage counters
Adds a new mir_dump output file in HTML/CSS to visualize code regions
and the MIR features that they came from (including overlapping spans).
See example below:

Includes a basic, MIR-block-based implementation of coverage injection,
available via `-Zexperimental-coverage`. This implementation has known
flaws and omissions, but is simple enough to validate the new tools and
tests.

The existing `-Zinstrument-coverage` option currently enables
function-level coverage only, which at least appears to generate
accurate coverage reports at that level.

Experimental coverage is not accurate at this time. When branch coverage
works as intended, the `-Zexperimental-coverage` option should be
removed.

This PR replaces the bulk of PR #75828, with the remaining parts of
that PR distributed among other separate and indentpent PRs.

This PR depends on three of those other PRs: #76000, #76002, and

Rust compiler MCP rust-lang/compiler-team#278

Relevant issue: #34701 - Implement support for LLVMs code coverage
instrumentation

![Screen-Recording-2020-08-21-at-2](https://user-images.githubusercontent.com/3827298/90972923-ff417880-e4d1-11ea-92bb-8713c6198f6d.gif)
2020-09-03 00:20:29 -07:00
Dan Aloni 07e7823c01 pretty: trim paths of unique symbols
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.

This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.

This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.

On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.

This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
2020-09-02 22:26:37 +03:00
Dan Aloni 7b2deb5628 rustc_{errors,session}: add `delay_good_path_bug`
The first use case of this detection of regression for trimmed paths
computation, that is in the case of rustc, which should be computed only
in case of errors or warnings.

Our current user of this method is deeply nested, being a side effect
from `Display` formatting on lots of rustc types. So taking only the
caller to the error message is not enough - we should collect the
traceback instead.
2020-09-02 10:43:17 +03:00
Tyler Mandry 4a6aa350c7
Rollup merge of #76158 - mati865:self-contained-option, r=petrochenkov
Stabilise link-self-contained option

MCP has been accepted: https://github.com/rust-lang/compiler-team/issues/343

I'll add improved heuristic in next PR.
2020-09-01 18:24:36 -07:00
jumbatm 93eaf15646 Add SessionDiagnostic derive macro.
Co-authored-by: Oliver Scherer <github35764891676564198441@oli-obk.de>
2020-09-01 22:02:45 +10:00
Rich Kadel 6b5869a0ae Add new `-Z dump-mir-spanview` option
Similar to `-Z dump-mir-graphviz`, this adds the option to write
HTML+CSS files that allow users to analyze the spans associated with MIR
elements (by individual statement, just terminator, or overall basic
block).

This PR was split out from PR #76004, and exposes an API for spanview
HTML+CSS files that is also used to analyze code regions chosen for
coverage instrumentation (in a follow-on PR).

Rust compiler MCP rust-lang/compiler-team#278

Relevant issue: #34701 - Implement support for LLVMs code coverage
instrumentation
2020-08-31 22:57:55 -07:00
Tyler Mandry 6d834a4046
Rollup merge of #76002 - richkadel:llvm-coverage-map-gen-6b.3, r=tmandry
Fix `-Z instrument-coverage` on MSVC

Found that `-C link-dead-code` (which was enabled automatically
under `-Z instrument-coverage`) was causing the linking error that
resulted in segmentation faults in coverage instrumented binaries. Link
dead code is now disabled under MSVC, allowing `-Z instrument-coverage`
to be enabled under MSVC for the first time.

More details are included in Issue #76038 .

Note this PR makes it possible to support `Z instrument-coverage` but
does not enable instrument coverage for MSVC in existing tests. It will be
enabled in another PR to follow this one (both PRs coming from original
PR #75828).

r? @tmandry
FYI: @wesleywiser
2020-08-31 19:18:14 -07:00
Rich Kadel ddb054aee8 Fix `-Z instrument-coverage` on MSVC
Found that -C link-dead-code (which was enabled automatically
under -Z instrument-coverage) was causing the linking error that
resulted in segmentation faults in coverage instrumented binaries. Link
dead code is now disabled under MSVC, allowing `-Z instrument-coverage`
to be enabled under MSVC for the first time.

More details are included in Issue #76038.

(This PR was broken out from PR #75828)
2020-08-31 18:41:13 -07:00
bors d824b23514 Auto merge of #75931 - estebank:suggest-if-let, r=petrochenkov
Suggest `if let x = y` when encountering `if x = y`

Detect potential cases where `if let` was meant but `let` was left out.

Fix #44990.
2020-09-01 00:26:01 +00:00
Aleksey Kladov 67f16431aa
Rollup merge of #76075 - marmeladema:remove-once-cell-crate, r=matklad
datastructures: replace `once_cell` crate with an impl from std

Fixes #75700

r? @matklad

We might need a perf run for this change.
2020-08-31 15:22:42 +02:00
Mateusz Mikuła 23f0ccfe5d Stabilise link-self-contained option 2020-08-31 15:13:31 +02:00
Aaron Hill d9208665b5
Add `-Z proc-macro-backtrace` to allow showing proc-macro panics
Fixes #75050

Previously, we would unconditionally suppress the panic hook during
proc-macro execution. This commit adds a new flag
-Z proc-macro-backtrace, which allows running the panic hook for
easier debugging.
2020-08-30 22:17:24 -04:00
Esteban Küber 07112ca62d Suggest `if let x = y` when encountering `if x = y`
Detect potential cases where `if let` was meant but `let` was left out.

Fix #44990.
2020-08-30 15:01:06 -07:00
marmeladema 68500ffacb datastructures: replace `once_cell` crate with an impl from std 2020-08-30 20:06:14 +01:00
mark 9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00