Rollup merge of #87385 - Aaron1011:final-enable-semi, r=petrochenkov
Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default
This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default.
To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon.
In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
Auto merge of #85971 - FabianWolff:issue-85586, r=davidtwco
Use more precise span for E0282 in cast expressions
This pull request fixes #85586. The example code given there:
```rust
fn main() {
let a = [1, 2, 3].iter().sum();
let b = (a + 1) as usize;
}
```
currently produces
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^^^^^^^^^^ cannot infer type
|
= note: type must be known at this point
error: aborting due to previous error
```
even though the type of the entire cast expression quite clearly should be `usize`. The error is in the cast's left-hand side, which is made explicit by the changes in this PR:
```
error[E0282]: type annotations needed
--> issue-85586.rs:3:13
|
3 | let b = (a + 1) as usize;
| ^^^^^^^ cannot infer type
|
= note: type must be known at this point
Auto merge of #87237 - jonas-schievink:const-for-and-try, r=oli-obk
Add feature gates for `for` and `?` in consts
These operations seems *relatively* straightforward to support, and only seem to be blocked on `impl const Trait`.
I have included a working test for `const_try`, but `const_for` is currently unusable without reimplementing *every single* defaulted `Iterator` method, so I didn't do that.
(both features still need tracking issues before this is merged)
Auto merge of #87615 - JohnTitor:rollup-t5jpmrg, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #87052 (Optimize fmt::PadAdapter::wrap)
- #87522 (Fix assert in diy_float)
- #87553 (Fix typo in rustc_driver::version)
- #87554 (2229: Discr should be read when PatKind is Range)
- #87564 (min_type_alias_impl_trait is going to be removed in 1.56)
- #87574 (Update the examples in `String` and `VecDeque::retain`)
- #87583 (Refactor compression cache in v0 symbol mangler)
- #87585 (Add missing links for core::char types)
- #87594 (fs File get_path procfs usage for netbsd same as linux.)
- #87602 ([backtraces]: look for the `begin` symbol only after seeing `end`)
Notice that `__rust_begin_short_backtrace` appears on frame 11 before
`__rust_end_short_backtrace` on frame 12. This is because in typical
release binaries without debug symbols, dbghelp.dll, which we use to walk
and symbolize the stack, does not know where CGU internal functions
start or end and so the closure invoked by `__rust_end_short_backtrace`
is incorrectly described as `__rust_begin_short_backtrace` because it
happens to be near that symbol.
While that can obviously change, this has been happening quite
consistently since #75048. Since this is a very small change to the std
and the change makes sense by itself, I think this is worth doing.
This doesn't completely resolve the situation for release binaries on
Windows, since without debug symbols, the stack printed can still show
incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
does slightly improve the situation in that you see the same backtrace
you would see with `RUST_BACKTRACE=full` or in a debugger (without the
uninteresting bits at the top and bottom).
Rollup merge of #87583 - tmiasko:compression-cache, r=wesleywiser
Refactor compression cache in v0 symbol mangler
* Remove redundant option around compression caches (they are always present).
* Flatten compression caches into symbol mangler to avoid dynamic memory allocation.
* Implement printer for `&mut SymbolMangler` instead of `SymbolMangler` to avoid passing now slightly larger symbol mangler by value.
Rollup merge of #87574 - cuviper:retain-examples, r=joshtriplett
Update the examples in `String` and `VecDeque::retain`
The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.
Rollup merge of #87564 - spastorino:adjust-min-tait-removed-version, r=jackh726
min_type_alias_impl_trait is going to be removed in 1.56
#87501 removed `min_type_alias_impl_trait` but meanwhile that PR was approved in homu queue, a new beta was cut so we need to bump the version because it won't be removed in 1.55.
Rollup merge of #87052 - phlopsi:patch-1, r=jyn514
Optimize fmt::PadAdapter::wrap
After adding the first `write!` usage to my project and printing the result to the console, I noticed, that my binary contains the strings "called `Option::unwrap()` on a `None` value`" and more importantly "C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs", with my release build being configured as follows:
```
[profile.release]
panic = "abort"
codegen-units = 1
strip = "symbols" # the important bit
lto = true
```
I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`.
Aside from me suspecting this function to be the culprit, the replaced code performs the same operation as `Option::insert`, but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore, it makes sense to me to use the more optimized version, instead.
As I don't change any semantics, I hope a simple pull request suffices.
Mir borrowck does not generate lifetime variables for 'static lifetimes during opaque type resolution
Fixes #87455
This situation was unreachable before #87287 as we used to just grab the resolved opaque type from typeck and replaced all regions with new inference vars. After #87287 we let the `InferCx` in mir borrowck figure out the opaque type all by itself (which it already did before, but it only used the result to sanity check with the typeck result).
Auto merge of #87285 - GuillaumeGomez:intra-doc-span, r=estebank
Improve intra doc errors display
#87169
`@jyn514` This is what I had in mind to avoid having duplicated backticks. I also gave a try to simply updating the span for the suggestion/help messages but I think this current one is better because less "noisy". Anyway, that allows you to see the result. ;)
Auto merge of #85901 - ijackson:bufwriter-tweaks, r=joshtriplett
Bufwriter disassembly tweaks
In #80690 `@BurntSushi` observed that `WriterPanicked` was erroneously not exported, and suggested renaming `into_raw_parts` to `into_parts`. (More info in my commit messages.)
Notice that `__rust_begin_short_backtrace` appears on frame 11 before
`__rust_end_short_backtrace` on frame 12. This is because in typical
release binaries without debug symbols, dbghelp.dll, which we use to walk
and symbolize the stack, does not know where CGU internal functions
start or end and so the closure invoked by `__rust_end_short_backtrace`
is incorrectly described as `__rust_begin_short_backtrace` because it
happens to be near that symbol.
While that can obviously change, this has been happening quite
consistently since #75048. Since this is a very small change to the std
and the change makes sense by itself, I think this is worth doing.
This doesn't completely resolve the situation for release binaries on
Windows, since without debug symbols, the stack printed can still show
incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
does slightly improve the situation in that you see the same backtrace
you would see with `RUST_BACKTRACE=full` or in a debugger (without the
uninteresting bits at the top and bottom).
Ian Jackson [Tue, 1 Jun 2021 15:47:26 +0000 (16:47 +0100)]
BufWriter: rename `into_parts` from `into_raw_parts`
I looked in stdlib and as @BurntSushi thought, `raw` is generally
used for raw pointers, or other hazardous kinds of thing. stdlib does
not have `into_parts` apart from the one I added to `IntoInnerError`.
I did an ad-hoc search of the rustdocs for my current game project
Otter, which includes quite a large number of dependencies.
`into_parts` seems heavily used for things quite like this.
So change this name.
Suggested-by: Andrew Gallant <jamslam@gmail.com> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Tomasz Miąsko [Thu, 29 Jul 2021 00:00:00 +0000 (00:00 +0000)]
Flatten compression caches into symbol mangler
The compression caches currently don't have any dedicated functionality
that would benefit from being separated. Incorporating caches directly
into the symbol manger also avoids dynamic memory allocation.
The symbol mangler, which is often passed by value, is now slightly
larger. This aspect will be addressed by a follow-up commit.
Auto merge of #86664 - m-ou-se:uninit-track-caller, r=JohnTitor
Add #[track_caller] for some function in core::mem.
These functions can panic for some types. This makes the panic point to the code that calls e.g. mem::uninitialized(), instead of inside the definition of mem::uninitialized.
Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str, r=oli-obk
Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.
panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
Auto merge of #87416 - Aaron1011:query-side-effect, r=cjgillot
Create `QuerySideEffects` and use it for diagnostics
The code for saving and loading diagnostics during execution is generalized to handle a new `QuerySideEffects` struct. Currently, this struct just holds diagnostics - in a follow-up PR, I plan to add support for storing attriutes marked as used during query execution.
This is a pure refactor, with no intended behavior changes.
Removes the implementations that depend on the user-definable trait `Copy`.
Fixes #85873 in the most straightforward way.
<hr>
_Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577.
With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`.
The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).
Josh Stone [Wed, 28 Jul 2021 23:35:59 +0000 (16:35 -0700)]
Update the examples in `String` and `VecDeque::retain`
The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.
Auto merge of #87569 - JohnTitor:rollup-7ydfetw, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #81050 (Stabilize core::task::ready!)
- #81363 (Remove P: Unpin bound on impl Future for Pin)
- #86839 (Add doc aliases to fs.rs)
- #87435 (fix example code for E0617)
- #87451 (Add support for tuple struct field documentation)
- #87491 (Integrate context into the memorial to Anna)
- #87521 (Add long explanation for E0498)
- #87527 (Don't run MIR unsafeck at all when using `-Zthir-unsafeck`)
- #87550 (Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly)
- #87565 (Use backticks when referring to `core::future::Ready` in panic message)
Rollup merge of #87491 - jamesmunns:integrate-memorial, r=Mark-Simulacrum
Integrate context into the memorial to Anna
This came up after I reviewed https://github.com/rust-lang/rust/pull/87298, but I didn't propose this in time before that PR was merged.
If y'all feel this is too much churn on the file, no worries, feel free to close, but I felt this was a more fitting integration of the memorial into the test suite.
Rollup merge of #81363 - jonhoo:no-unpin-in-pin-future-impl, r=m-ou-se
Remove P: Unpin bound on impl Future for Pin
We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.
The `Unpin` bound was originally added in #56939 following the recommendation of ``@withoutboats`` in https://github.com/rust-lang/rust/issues/55766#issue-378417538
That comment does not give explicit justification for why the bound should be added. The relevant context was:
> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.
The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886, this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed.
The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.
Mara Bos [Tue, 6 Jul 2021 12:38:26 +0000 (12:38 +0000)]
Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.
panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
Auto merge of #7502 - flip1995:rollup-y3ho3w0, r=flip1995
Rollup of 3 pull requests
Successful merges:
- #7279 (Adapting the lint list to Clippy's new metadata format)
- #7298 (Switch CI to new metadata collection)
- #7420 (Update lint documentation to use markdown headlines)
Philipp Krones [Wed, 28 Jul 2021 13:06:27 +0000 (15:06 +0200)]
Rollup merge of #7420 - xFrednet:7172-update-lint-documentation, r=flip1995
Update lint documentation to use markdown headlines
This PR updates all lint documentation to use markdown headlines. It additionally removed the *Known problems* section for lints without any problems. I've double-checked all automatic replacements, but a second pair of eyes is definitely appreciated!
I wasn't sure when you wanted to switch to the new metadata collection tomorrow, I therefore prepared this PR today. And that's it this is a standalone PR to keep the other related PRs reviewable.
changelog: none
r? `@flip1995`
cc: #7172
Note: This should be merged with the other metadata collection related PRs.
Philipp Krones [Wed, 28 Jul 2021 13:06:26 +0000 (15:06 +0200)]
Rollup merge of #7298 - flip1995:ci-switch-to-monster, r=xFrednet,flip1995
Switch CI to new metadata collection
r? `@xFrednet`
Things we have to keep in mind:
- This removes the template files and the scripts used for deployment from the checkout. This was added in #5517. I don't think we ever needed those there. Not sure though.
- ~~As a result, we can't remove the python scripts yet. We have to wait until this hits a stable Clippy release.~~ I'll just break the next stable deploy and do it by hand once.
- This should be merged together with #7279. Me and `@xFrednet` will coordinate the switch
- ...?
I still have to try out some things:
- [x] Is it worth caching? Yes
- [x] ~~Is it worth to do a release build?~~ Nope
- [x] Does it actually work? With a few changes, yes
- [ ] ...?
changelog: Clippy now uses a lint to generate its documentation :tada:
Philipp Krones [Wed, 28 Jul 2021 13:06:26 +0000 (15:06 +0200)]
Rollup merge of #7279 - xFrednet:7172-adapt-website-to-new-format, r=flip1995
Adapting the lint list to Clippy's new metadata format
This is close to the end of a long living project to rewrite the lint metadata collection for Clippy. Progress on this has been tracked in #7172. This PR adds one of the last missing puzzle pieces, the actual display of all the changes that have been done in the background. A preview can be seen here: [Clippy's lint list](https://xfrednet.github.io/rust-clippy/master/index.html)
The styling has been discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Styling.20feedback.20for.20Clippy's.20lint.20list/near/239601067) but is still open to suggestion.
Side note: It has been fun working on the website where we don't have unit tests and everything is just tested by playing around. However, it's good that this chaos is contained into this one part of Clippy. :bug:
---
Closes: #1303 Closes: #4310
This actually closes fewer things than I thought it would...
changelog: Reworked Clippy's [website](https://rust-lang.github.io/rust-clippy/master/index.html):
changelog: * Added applicability information about lints
changelog: * Added a link to jump to the specific lint implementation
changelog: * Adapted some styling and improved loading time
xFrednet [Tue, 18 May 2021 22:08:31 +0000 (00:08 +0200)]
Adapting the lint list to Clippy's new metadata format
Changes included:
- Minimum adaption to the new `lints.json` format
- Fixing filtering for the new `lints.json` format; hardcoding the
lint groups in the index
- Recreating the original doc styling for the new format
- Fixed sytax highlighting for rust,ignore code blocks
- Fixed markdown table extraction in the metadata collector and
fixed lint level output
- Adding the additional information row for lints
- Changed the website title to Clippy's lint list
- Flexing the website for mobile users
- Added (?) references for lint levels and groups
- Making deprecated lints look dead
- Removed JS code block language extraction in favor of a rust
implementation `rust-clippy#7352`
- Added the suspicious lint group to the lint list
- Remove trailing whitespaces from index.html
- Fix code highlighting
- Use default value if the docVersion is empty
Co-authored-by: Philipp Krones <hello@philkrones.com>
Mara Bos [Sun, 27 Jun 2021 12:41:50 +0000 (12:41 +0000)]
Add #[track_caller] for some function in core::mem.
These functions can panic for some types. This makes the panic point to
the code that calls e.g. mem::uninitialized(), instead of inside the
definition of mem::uninitialized.
Frank Steffahn [Thu, 3 Jun 2021 13:53:12 +0000 (15:53 +0200)]
Improve documentation of TrustedRandomAccess
Include new details regarding coercions to a subtype.
These conditions also explain why the previously removed implementations
for {array, vec, vec_deque}::IntoIter<T> were unsound, because they introduced
an extra `T: Clone` for the TrustedRandomAccess impl, even though their parameter T
is covariant.
projects / rust.git / log