Yuki Okushi [Wed, 30 Jun 2021 20:20:59 +0000 (05:20 +0900)]
Rollup merge of #86740 - 1000teslas:issue-71519-fix, r=petrochenkov
copy rust-lld as ld in dist
Fixes bug in https://github.com/rust-lang/rust/pull/85961. Linking seems to work for pure Rust projects, but not when a C library needs to be dynamically linked.
Yuki Okushi [Wed, 30 Jun 2021 20:20:58 +0000 (05:20 +0900)]
Rollup merge of #86728 - FabianWolff:issue-86721, r=LeSeulArtichaut
Check node kind to avoid ICE in `check_expr_return()`
This PR fixes #86721. The ICE described there is apparently due to a misunderstanding:
https://github.com/rust-lang/rust/blob/e98897e5dc9898707bf4331c43b2e76ab7e282fe/compiler/rustc_typeck/src/check/expr.rs#L684-L685
Intuitively, one would think that calling `expect_item()` after `get_parent_item()` should succeed, but as it turns out, `get_parent_item()` can also return foreign, trait, and impl items as well as crates, whereas `expect_item()` specifically expects a `Node::Item`. I have therefore added an extra check to prevent this ICE.
Yuki Okushi [Wed, 30 Jun 2021 20:20:55 +0000 (05:20 +0900)]
Rollup merge of #85520 - FabianWolff:issue-85475, r=jackh726
Fix typo and improve documentation for E0632
Edit: After https://github.com/rust-lang/rust/pull/85520#issuecomment-870095546, this PR has been boiled down to just an extended description for `E0632` and a fixed typo.
bors [Wed, 30 Jun 2021 18:14:16 +0000 (18:14 +0000)]
Auto merge of #7400 - popzxc:restrict-locales, r=Manishearth
New lint: `disallowed_script_idents`
This PR implements a new lint to restrict locales that can be used in the code,
as proposed in #7376.
Current concerns / unresolved questions:
- ~~Mixed usage of `script` (as a Unicode term) and `locale` (as something that is easier to understand for the broad audience). I'm not sure whether these terms are fully interchangeable and whether in the current form it is more confusing than helpful.~~ `script` is now used everywhere.
- ~~Having to mostly copy-paste `AllowedScript`. Probably it's not a big problem, as the list of scripts is standardized and is unlikely to change, and even if we'd stick to the `unicode_script::Script`, we'll still have to implement custom deserialization, and I don't think that it will be shorter in terms of the amount of LoC.~~ `unicode::Script` is used together with a filtering deserialize function.
- Should we stick to the list of "recommended scripts" from [UAX #31](http://www.unicode.org/reports/tr31/#Table_Recommended_Scripts) in the configuration?
*Please write a short comment explaining your change (or "none" for internal only changes)*
Daniel Paoliello [Thu, 24 Jun 2021 17:36:28 +0000 (10:36 -0700)]
Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types).
Instead, each debug symbol name should be unique and useful:
* Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.
* Qualify the principal trait for dynamic types.
* If there is no principal trait for a dynamic type, emit all other traits instead.
* Respect the `qualified` argument when emitting ref and pointer types.
* For implementations, emit the disambiguator.
* Print const generics when emitting generic parameters or arguments.
Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
* Avoid characters with special meaning (`#`, `[`, `"`, `+`).
* Never start a name with `<` or `{` as this is treated as an operator.
* `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).
* Emit function declarations using C/C++ style syntax (e.g., leading return type).
* Emit arrays as a synthetic `array$<type, size>` type.
* Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
bors [Wed, 30 Jun 2021 10:54:08 +0000 (10:54 +0000)]
Auto merge of #86650 - GuillaumeGomez:fix-boldness, r=Nemo157
Fix boldness (put it back where needed)
I realized that I created a GUI test that wasn't run because it had ".rs" extension instead of ".goml" so I moved its content into `font-weight.goml` (since it was checking font weight).
bors [Wed, 30 Jun 2021 05:02:01 +0000 (05:02 +0000)]
Auto merge of #86689 - rylev:future-compat-lint-group, r=nikomatsakis
Only include lint in future_incompatible lint group if not an edition lint
A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition.
We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though.
- issues/issue-27060.rs: misclassified, should be packed.
- issues/issue-45157.rs: moved to nll.
- issues/issue-69532.rs: ~~couldn't figured out the best place, placed a new `llvm` dir~~ moved to consts.
- fsu-moves-and-copies.rs: moved to borrowck.
- issues/issue-36638.rs: misclassified, moved to keyword.
- issues/issue-48636.rs: moved to parser.
- issues/issue-37655.rs: I'm not sure but associated-types shouldn't the best, moved to coercion but region may be better.
- issues/issue-20005.rs: moved to associated-types.
- issues/issue-82869.rs: moved to asm.
- issues/issue-24535-allow-mutable-borrow-in-match-guard.rs: moved to nll.
- issues/issue-52169.rs: moved to macros.
- test-passed.rs: moved to test-attrs along with `test-` prefixed tests.
- test-cfg.rs: moved to conditional-compilation.
- non-integer-atomic.rs: moved to intrinsics.
- issues/issue-54521-2.rs: moved to parser.
- issues/issue-17756.rs: moved to consts.
- conversion-methods.rs: ~~moved to suggestions~~ moved to typeck.
bors [Tue, 29 Jun 2021 20:59:14 +0000 (20:59 +0000)]
Auto merge of #86725 - JohnTitor:normalizecss-8, r=GuillaumeGomez
Upgrade normalize.css to v8.0.1
Fixes #86629, this addresses #82548 and #82542 with tweaks. I expect that this changes the style *slightly* but shouldn't have any major changes.
Here's some changes I observed, I'd say they all are an improvement.
bors [Tue, 29 Jun 2021 13:03:45 +0000 (13:03 +0000)]
Auto merge of #7405 - jyn514:fix-stable, r=camsteffen
Stabilize `cargo clippy --fix`
This has been unstable since it was first introduced in
https://github.com/rust-lang/rust-clippy/pull/5363. In that time, I have
been using it successfully in nightly without issues. I don't think
there are any blocking issues now that RUSTC_WORKSPACE_WRAPPER is
stabilized, so this can be stabilized.
bors [Tue, 29 Jun 2021 08:53:59 +0000 (08:53 +0000)]
Auto merge of #7409 - xFrednet:5394-vs-code-tasks, r=giraffate,flip1995
Added `cargo dev setup vscode-tasks` for simplicity
This PR adds a setup command to `clippy dev` that installs tasks into the Clippy vscode workspace. These might be useful as they be used via shortcuts and are accessible over the GUI. The available tasks are:
* `cargo check` (standard Linux shortcut `[ctrl] + [shift] + b`)
* `cargo dev fmt`
* `cargo uitest` (with a comment how to add the `TESTNAME` environment value)
* `cargo test`
* `cargo dev bless`
---
changelog: none
only internal changes again. cc #5394
r? `@flip1995` This should be pretty much the same as the other `cargo dev setup` commands. Would you mind reviewing this? :upside_down_face:
Joshua Nelson [Sat, 26 Jun 2021 01:41:56 +0000 (21:41 -0400)]
Stabilize `cargo clippy --fix`
This has been unstable since it was first introduced in
https://github.com/rust-lang/rust-clippy/pull/5363. In that time, I have
been using it successfully in nightly without issues. I don't think
there are any blocking issues now that RUSTC_WORKSPACE_WRAPPER is
stabilized, so this can be stabilized.
Yuki Okushi [Mon, 28 Jun 2021 23:46:16 +0000 (08:46 +0900)]
Rollup merge of #86678 - FabianWolff:issue-86667, r=jackh726
Fix garbled suggestion for missing lifetime specifier
This PR fixes #86667. The suggestion code currently checks whether there is a generic parameter that is not a synthetic `impl Trait` parameter and, if so, suggests to insert a new lifetime `'a` before that generic parameter. However, it does not make sense to insert `'a` in front of an elided lifetime parameter, since these are synthetic as well, which leads to the garbled suggestion in #86667.
Yuki Okushi [Mon, 28 Jun 2021 23:46:14 +0000 (08:46 +0900)]
Rollup merge of #86671 - m-ou-se:non-fmt-panic-future-incompatible, r=nikomatsakis
Turn non_fmt_panic into a future_incompatible edition lint.
This turns the `non_fmt_panic` lint into a future_incompatible edition lint, so it becomes part of the `rust_2021_compatibility` group. See https://github.com/rust-lang/rust/issues/85894.
This lint produces both warnings about semantical changes (e.g. `panic!("{{")`) and things that will become hard errors (e.g. `panic!("{")`). So I added a `explain_reason: false` that supresses the default "this will become a hard error" or "the semantics will change" message, and instead added a note depending on the situation. (cc `@rylev)`
Yuki Okushi [Mon, 28 Jun 2021 23:46:11 +0000 (08:46 +0900)]
Rollup merge of #86657 - jam1garner:future_prelude_false_positive, r=nikomatsakis
Fix `future_prelude_collision` false positive
Fixes #86633
The lint for checking if method resolution of methods named `try_into` will fail in 2021 edition previously would fire on all inherent methods, however for inherent methods that consume `self`, this takes priority over `TryInto::try_into` due to being inherent, while trait method and methods that take `&self` or `&mut self` don't take priority, and thus aren't affected by this false positive.
This fix is rather simple: simply checking if the inherent method doesn't auto-deref or auto-ref (and thus takes `self`) and if so, prevents the lint from firing.
Yuki Okushi [Mon, 28 Jun 2021 23:46:10 +0000 (08:46 +0900)]
Rollup merge of #86529 - cuviper:ssl3, r=Mark-Simulacrum
Add support for OpenSSL 3.0.0
This updates the `openssl` and `openssl-sys` crates to support building
the toolchain with system libraries up to OpenSSL 3.0.0. This does not
affect the static version used via `openssl-src` in CI builds.
bors [Mon, 28 Jun 2021 21:37:57 +0000 (21:37 +0000)]
Auto merge of #86669 - Smittyvb:satisfy-windows-defender, r=Mark-Simulacrum
Don't run a publically reachable server in tests
This causes Windows Defender's firewall to pop up during tests to ask if I want to allow the test program to access the public Internet, since it was listening on `0.0.0.0` (the test passes regardless of how you respond to the modal, since the firewall only affects traffic outside of the computer, none of which actually happens in the test). The test server doesn't actually need to be publicly reachable, so this makes it so it is only reachable locally, which makes Windows Defender happy.
Smitty [Mon, 28 Jun 2021 18:39:20 +0000 (14:39 -0400)]
Make incomplete features part of delcaration
This prevents mistakes where the feature is in the list of incomplete
features but not actually a feature by making the incompleteness a part
of the declaration.
bors [Mon, 28 Jun 2021 16:48:01 +0000 (16:48 +0000)]
Auto merge of #86690 - JohnTitor:rollup-4ukk4yw, r=JohnTitor
Rollup of 6 pull requests
Successful merges:
- #86206 (Fix type checking of return expressions outside of function bodies)
- #86358 (fix pretty print for `loop`)
- #86568 (Don't dist miri or rust-analyzer on stable or beta.)
- #86683 (:arrow_up: rust-analyzer)
- #86687 (Allow anyone to set `perf-regression` label)
- #86688 (Add a regression test for issue-65384)
Add new tool to check HTML:
* Make html-checker run by default on rust compiler docs as well
* Ensure html-checker is run on CI
* Lazify tidy binary presence check
Yuki Okushi [Mon, 28 Jun 2021 15:26:57 +0000 (00:26 +0900)]
Rollup merge of #86568 - ehuss:dist-miri-stable, r=Mark-Simulacrum
Don't dist miri or rust-analyzer on stable or beta.
This prevents miri and rust-analyzer from being built for "dist" or "install" on the stable/beta channels. It is a nightly-only tool and should not be included.
Yuki Okushi [Mon, 28 Jun 2021 15:26:54 +0000 (00:26 +0900)]
Rollup merge of #86206 - FabianWolff:issue-86188, r=Mark-Simulacrum
Fix type checking of return expressions outside of function bodies
This pull request fixes #86188. The problem is that the current code for type-checking `return` expressions stops if the `return` occurs outside of a function body, while the correct behavior is to continue type-checking the return value expression (otherwise an ICE happens later on because variables declared in the return value expression don't have a type).
Also, I have noticed that it is sometimes not obvious why a `return` is outside of a function body; for instance, in the example from #86188 (which currently causes an ICE):
```rust
fn main() {
[(); return || {
let tx;
}]
}
```
I have changed the error message to also explain why the `return` is considered outside of the function body:
```
error[E0572]: return statement outside of function body
--> ice0.rs:2:10
|
1 | / fn main() {
2 | | [(); return || {
| |__________^
3 | || let tx;
4 | || }]
| ||_____^ the return is part of this body...
5 | | }
| |_- ...not the enclosing function body
```
bors [Mon, 28 Jun 2021 08:35:51 +0000 (08:35 +0000)]
Auto merge of #7350 - camsteffen:suspicious, r=flip1995
Add suspicious group
changelog: Introduce `clippy::suspicious` 🤔 group and move several lints into the group
Closes #6366. CC #6626.
A number of lints are moved from each of `correctness`, `style` and `complexity` groups. Notably I didn't move `suspicious_splitn` since I think that is a `correctness` lint despite the name.
bors [Mon, 28 Jun 2021 06:24:49 +0000 (06:24 +0000)]
Auto merge of #86684 - inquisitivecrystal:libs-tracking-issue, r=m-ou-se
Fix typo in libs tracking issue template
Currently, the libs tracking issue template expands FCP as "final commenting period". Everywhere else, including in [the official explanation](https://rust-lang.github.io/rfcs/), it's expanded as "final comment period". That version also sounds a bit better. Accordingly, this PR changes the tracking issue template to use that version.
projects / rust.git / log