```
$ grep -Ri "good first issue" rust-clippy/
rust-clippy/.git/COMMIT_EDITMSG:Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/.git/logs/HEAD:896d82f7ff64644656bda7a4ed8bbd55ca3b76191f58c2bb8a638a63edc1f3503c8771937aa19157 xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/HEAD:9be704584f05e5a6c3ba2708590f98c1f261d19aced54f28671ddb9ccf9b44131d522f4fdeab7097 xFrednet <xFrednet@gmail.com> 1608329602 +0000 commit: Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/.git/logs/refs/heads/0000-rename-good-first-issue-in-docs:896d82f7ff64644656bda7a4ed8bbd55ca3b76191f58c2bb8a638a63edc1f3503c8771937aa19157 xFrednet <xFrednet@gmail.com> 1608326295 +0000 commit: Renamed the good first issue label for rustbot
rust-clippy/.git/logs/refs/heads/0000-rename-good-first-issue-in-docs:9be704584f05e5a6c3ba2708590f98c1f261d19aced54f28671ddb9ccf9b44131d522f4fdeab7097 xFrednet <xFrednet@gmail.com> 1608329602 +0000 commit: Renamed the good first issue label in CONTRIBUTING.md
rust-clippy/CONTRIBUTING.md:Some issues are easier than others. The [`good first issue`] label can be used to find the easy issues.
rust-clippy/CONTRIBUTING.md:[`E-medium`] issues are generally pretty easy too, though it's recommended you work on an [`good first issue`]
rust-clippy/CONTRIBUTING.md:[`good first issue`]: https://github.com/rust-lang/rust-clippy/labels/good%20first%20issue
```
</details>
bors [Fri, 18 Dec 2020 21:25:39 +0000 (21:25 +0000)]
Auto merge of #6468 - xFrednet:0000-rename-good-first-issue-for-rustbot, r=flip1995
Renamed the good first issue label for rustbot
The `good first issue` label got renamed to `good-first-issue`. See [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Rename.20the.20.22good.20first.20issue.22.20label.20for.20bot.20usage/near/220428379) to enable the assignment with rustbot.
xFrednet [Fri, 18 Dec 2020 21:18:15 +0000 (21:18 +0000)]
Renamed the good first issue label for rustbot
See https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Rename.20the.20.22good.20first.20issue.22.20label.20for.20bot.20usage/near/220428018
Nadrieril [Thu, 17 Dec 2020 01:56:22 +0000 (01:56 +0000)]
Unify the two kinds of usefulness merging
This is elegant but a bit of a perf gamble. That said, or-patterns
rarely have many branches and it's easy to optimize or revert if we ever
need to. In the meantime simpler code is worth it.
Ralf Jung [Fri, 18 Dec 2020 15:22:07 +0000 (16:22 +0100)]
Rollup merge of #80130 - pierwill:patch-7, r=oli-obk
docs: Edit rustc_span::symbol::Symbol method
Edit wording of the doc comment for [rustc_span::symbol::Symbol::can_be_raw](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html#method.can_be_raw) to match related methods.
bors [Fri, 18 Dec 2020 08:44:50 +0000 (08:44 +0000)]
Auto merge of #80090 - jyn514:tcx-in-render, r=GuillaumeGomez
Pass a `TyCtxt` through to `FormatRender`
This is the next step after https://github.com/rust-lang/rust/pull/79957 for https://github.com/rust-lang/rust/issues/76382. Eventually I plan to use this to remove `stability`, `const_stability`, and `deprecation` from `Item`, but that needs more extensive changes (in particular, https://github.com/rust-lang/rust/pull/75355 or something like it).
This has no actual changes to behavior, it's just moving types around.
Before this change, finding an error when parsing a doctest would make Clippy exit without emitting an error. Now we properly catch a fatal error and ignore it.
Also, if a doctest specifies an edition in the info line, it will be used when parsing it.
bors [Fri, 18 Dec 2020 03:01:14 +0000 (03:01 +0000)]
Auto merge of #80036 - sivadeilra:syms_no_macro, r=petrochenkov
Stop using intermediate macros in definition of symbols
Currently, the rustc_macros::symbols macro generates two
`macro_rules!` macros as its output. These two macros are
used in rustc_span/src/symbol.rs.
This means that each Symbol that we define is represented
in the AST of rustc_symbols twice: once in the definition
of the `define_symbols!` macro (similarly for the
`keywords! macro), and once in the rustc_span::symbols
definition.
That would be OK if there were only a handful of symbols,
but currently we define over 1100 symbols. The definition
of the `define_symbols!` macro contains the expanded definition
of each symbol, so that's a lot of AST storage wasted on a
macro that is used exactly once.
This commit removes the `define_symbols` macro, and simply
allows the proc macro to directly generate the
`rustc_symbols::symbol::sym` module.
The benefit is mainly in reducing memory wasted during
compilation of rustc itself. It should also reduce memory used
by Rust Analyzer.
This commit also reduces the size of the AST for symbol
definitions, by moving two `#[allow(...)]` attributes from
the symbol constants to the `sym` module. This eliminates 2200+
attribute nodes.
This commit also eliminates the need for the `digits_array`
constant. There's no need to store an array of Symbol values
for digits. We can simply define a constant of the base value,
and add to that base value.
I left the `sym::integer` function in rustc_span/src/symbol.rs
instead of moving it into rustc_macros/src/symbols.rs for two
reasons. First, because it's human-written code; it doesn't need
to be generated by the proc-macro. Second, because I didn't want
the `#[allow(...)]` attributes that I moved to the `sym` module
scope to apply to this function. The `sym` module re-exports the
`integer` function from its parent module.
bors [Fri, 18 Dec 2020 00:08:30 +0000 (00:08 +0000)]
Auto merge of #80138 - Dylan-DPC:rollup-qamsfyh, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #78164 (Prefer regions with an `external_name` in `approx_universal_upper_bound`)
- #80003 (Fix overflow when converting ZST Vec to VecDeque)
- #80023 (Enhance error message when misspelled label to value in break expression)
- #80046 (Add more documentation to `Diagnostic` and `DiagnosticBuilder`)
- #80109 (Remove redundant and unreliable coverage test results)
Dylan DPC [Thu, 17 Dec 2020 23:30:21 +0000 (00:30 +0100)]
Rollup merge of #80109 - richkadel:llvm-coverage-counters-2.3.0, r=tmandry
Remove redundant and unreliable coverage test results
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
r? `@tmandry`
Tyler - as we discussed offline...
FYI: `@wesleywiser` `@Swatinem`
Arpad, depending on the timing of this PR, it may not affect you, but I'm removing some of the files that produce slightly different results on Windows as they really aren't necessary to validate coverage results.
Dylan DPC [Thu, 17 Dec 2020 23:30:11 +0000 (00:30 +0100)]
Rollup merge of #80003 - Stupremee:fix-zst-vecdeque-conversion-panic, r=dtolnay
Fix overflow when converting ZST Vec to VecDeque
```rust
let v = vec![(); 100];
let queue = VecDeque::from(v);
println!("{:?}", queue);
```
This code will currently panic with a capacity overflow.
This PR resolves this issue and makes the code run fine.
Dylan DPC [Thu, 17 Dec 2020 23:30:09 +0000 (00:30 +0100)]
Rollup merge of #78164 - Aaron1011:fix/async-region-name, r=tmandry
Prefer regions with an `external_name` in `approx_universal_upper_bound`
Fixes #75785
When displaying a MIR borrowcheck error, we may need to find an upper
bound for a region, which gives us a region to point to in the error
message. However, a region might outlive multiple distinct universal
regions, in which case the only upper bound is 'static
To try to display a meaningful error message, we compute an
'approximate' upper bound by picking one of the universal regions.
Currently, we pick the region with the lowest index - however, this
caused us to produce a suboptimal error message in issue #75785
This PR `approx_universal_upper_bound` to prefer regions with an
`external_name`. This causes us to prefer regions from function
arguments/upvars, which seems to lead to a nicer error message in some
cases.
Arlie Davis [Mon, 14 Dec 2020 19:34:55 +0000 (11:34 -0800)]
Stop using intermediate macros in definition of symbols
Currently, the rustc_macros::symbols macro generates two
`macro_rules!` macros as its output. These two macros are
used in rustc_span/src/symbol.rs.
This means that each Symbol that we define is represented
in the AST of rustc_symbols twice: once in the definition
of the `define_symbols!` macro (similarly for the
`keywords! macro), and once in the rustc_span::symbols
definition.
That would be OK if there were only a handful of symbols,
but currently we define over 1100 symbols. The definition
of the `define_symbols!` macro contains the expanded definition
of each symbol, so that's a lot of AST storage wasted on a
macro that is used exactly once.
This commit removes the `define_symbols` macro, and simply
allows the proc macro to directly generate the
`rustc_symbols::symbol::sym` module.
The benefit is mainly in reducing memory wasted during
compilation of rustc itself. It should also reduce memory used
by Rust Analyzer.
This commit also reduces the size of the AST for symbol
definitions, by moving two `#[allow(...)]` attributes from
the symbol constants to the `sym` module. This eliminates 2200+
attribute nodes.
This commit also eliminates the need for the `digits_array`
constant. There's no need to store an array of Symbol values
for digits. We can simply define a constant of the base value,
and add to that base value.
bors [Thu, 17 Dec 2020 21:13:51 +0000 (21:13 +0000)]
Auto merge of #80122 - davidtwco:revert-76030, r=oli-obk
Revert "cg_llvm: `fewer_names` in `uncached_llvm_type`"
Fixes #76213 and fixes #79564.
This PR temporarily reverts commit fa01ce802f1b403a2140fd945b43af86ec3998a1 from #76030 to until the root issue can be resolved. Requested [in t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.20meeting.5D.202020-12-17.20.2354818/near/220261541).
*Note*: I was seeing some failing debuginfo-gdb tests locally but I wasn't sure if they were spurious.
Aaron Hill [Tue, 20 Oct 2020 20:31:54 +0000 (16:31 -0400)]
Prefer regions with an `external_name` in `approx_universal_upper_bound`
Fixes #75785
When displaying a MIR borrowcheck error, we may need to find an upper
bound for a region, which gives us a region to point to in the error
message. However, a region might outlive multiple distinct universal
regions, in which case the only upper bound is 'static
To try to display a meaningful error message, we compute an
'approximate' upper bound by picking one of the universal regions.
Currently, we pick the region with the lowest index - however, this
caused us to produce a suboptimal error message in issue #75785
This PR `approx_universal_upper_bound` to prefer regions with an
`external_name`. This causes us to prefer regions from function
arguments/upvars, which seems to lead to a nicer error message in some
cases.
bors [Thu, 17 Dec 2020 14:52:50 +0000 (14:52 +0000)]
Auto merge of #80113 - davidtwco:issue-80086-ci-llvm-stamp, r=Mark-Simulacrum
bootstrap: update ci-llvm stamp after #80087
Fixes #80086.
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This PR updates the ci-llvm stamp to resolve that problem.
bors [Thu, 17 Dec 2020 12:02:29 +0000 (12:02 +0000)]
Auto merge of #80114 - GuillaumeGomez:rollup-gszr5kn, r=GuillaumeGomez
Rollup of 5 pull requests
Successful merges:
- #80006 (BTreeMap: more expressive local variables in merge)
- #80022 (BTreeSet: simplify implementation of pop_first/pop_last)
- #80035 (Optimization for bool's PartialOrd impl)
- #80040 (Always run intrinsics lowering pass)
- #80047 (Use more symbols in rustdoc)
Guillaume Gomez [Thu, 17 Dec 2020 10:36:54 +0000 (11:36 +0100)]
Rollup merge of #80047 - jyn514:more-symbols, r=GuillaumeGomez
Use more symbols in rustdoc
Builds on https://github.com/rust-lang/rust/pull/80044 and should not be merged before.
I want to test if this is actually faster before merging it, there was a lot of `to_string()` calls so I'm not sure it will actually help. That means I have to wait for 80044 to get merged before running perf.
Guillaume Gomez [Thu, 17 Dec 2020 10:36:52 +0000 (11:36 +0100)]
Rollup merge of #80040 - tmiasko:always-lower-intrinsics, r=Dylan-DPC
Always run intrinsics lowering pass
Move intrinsics lowering pass from the optimization phase (where it
would not run if -Zmir-opt-level=0), to the drop lowering phase where it
runs unconditionally.
The implementation of those intrinsics in code generation and
interpreter is unnecessary. Remove it.
David Wood [Thu, 17 Dec 2020 10:29:58 +0000 (10:29 +0000)]
bootstrap: update ci-llvm stamp after #80087
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated
ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This commit
updates the ci-llvm stamp to resolve that problem.
Rich Kadel [Thu, 17 Dec 2020 06:07:40 +0000 (22:07 -0800)]
Remove redundant and unreliable coverage test results
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
Yuki Okushi [Thu, 17 Dec 2020 02:44:12 +0000 (11:44 +0900)]
Rollup merge of #80097 - SimonSapin:popcount, r=m-ou-se
Add `popcount` and `popcnt` as doc aliases for `count_ones` methods.
Integer types have a `count_ones` method that end up calling `intrinsics::ctpop`. On some architectures, that intrinsic is translated as a corresponding CPU instruction know as "popcount" or "popcnt".
This PR makes it so that searching for those names in rustdoc shows those methods.
CC https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#adding-search-aliases
Yuki Okushi [Thu, 17 Dec 2020 02:44:10 +0000 (11:44 +0900)]
Rollup merge of #80082 - ehuss:revert-rust-src-vendor, r=Mark-Simulacrum
Revert #78790 - rust-src vendoring
This reverts the rust-src vendor changes from #78790. There were a few issues (see #79218, https://github.com/rust-lang/cargo/issues/8962, https://github.com/rust-lang/cargo/issues/8963), that I don't think will get fixed in the next few days before the beta branch.
Yuki Okushi [Thu, 17 Dec 2020 02:44:06 +0000 (11:44 +0900)]
Rollup merge of #80072 - richkadel:llvm-coverage-counters-2.2.1, r=tmandry
Fixed conflict with drop elaboration and coverage
See
https://github.com/rust-lang/rust/issues/80045#issuecomment-745733339
Coverage statements are moved to the beginning of the BCB. This does
also affect what's counted before a panic, changing some results, but I
think these results may even be preferred? In any case, there are no
guarantees about what's counted when a panic occurs (by design).
But that is not always a safe thing to do -- sometimes the early `otherwise` branch is necessary so the later block could assume the value of `discriminant(X)`.
I am not totally sure what's the best way to detect that, but fixing #78496 should be easy -- we just check if `X` is a sub-expression of `Y`. A more precise test might be to check if `Y` contains a `Downcast(1)` of `X`, but I think this might be good enough.
Yuki Okushi [Thu, 17 Dec 2020 02:43:57 +0000 (11:43 +0900)]
Rollup merge of #79877 - bstrie:depinfut, r=oli-obk
Allow `since="TBD"` for rustc_deprecated
Closes #78381.
This PR only affects `#[rustc_deprecated]`, not `#[deprecated]`, so there is no effect on any stable language feature.
Likewise this PR only implements `since="TBD"`, it does not actually tag any library functions with it, so there is no effect on any stable API.
Overview of changes:
* `rustc_middle/stability.rs`:
* change `deprecation_in_effect` function to return `false` when `since="TBD"`
* tidy up the compiler output when a deprecated item has `since="TBD"`
* `rustc_passes/stability.rs`:
* allow `since="TBD"` to pass the sanity check for stable_version < deprecated_version
* refactor the "invalid stability version" and "invalid deprecation version" error into separate errors
* rustdoc: make `since="TBD"` message on a deprecated item's page match the command-line deprecation output
* tests:
* test rustdoc output
* test that the `deprecated_in_future` lint fires when `since="TBD"`
* test the new "invalid deprecation version" error message
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` :heart: for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now