| Age | Commit message (Collapse) | Author | Lines |
|---|
|
When encountering method call chains of `Iterator`, check for trailing
`;` in the body of closures passed into `Iterator::map`, as well as
calls to `<T as Clone>::clone` when `T` is a type param and `T: !Clone`.
Fix #9082.
|
|
const-eval: make misalignment a hard error
It's been a future-incompat error (showing up in cargo's reports) since https://github.com/rust-lang/rust/pull/104616, Rust 1.68, released in March. That should be long enough.
The question for the lang team is simply -- should we move ahead with this, making const-eval alignment failures a hard error? (It turns out some of them accidentally already were hard errors since #104616. But not all so this is still a breaking change. Crater found no regression.)
|
|
`type` turned out to be controversial.
|
|
|
|
|
|
Detect ruby-style closure in parser
When parsing a closure without a body that is surrounded by a block, suggest moving the opening brace after the closure head.
Fix #116608.
|
|
|
|
Fix #101351.
When an associated type on a type parameter is used, and the type
parameter isn't constrained by the correct trait, suggest the
appropriate trait bound:
```
error[E0220]: associated type `Associated` not found for `T`
--> file.rs:6:15
|
6 | field: T::Associated,
| ^^^^^^^^^^ there is a similarly named associated type `Associated` in the trait `Foo`
|
help: consider restricting type parameter `T`
|
5 | struct Generic<T: Foo> {
| +++++
```
When an associated type on a type parameter has a typo, suggest fixing
it:
```
error[E0220]: associated type `Baa` not found for `T`
--> $DIR/issue-55673.rs:9:8
|
LL | T::Baa: std::fmt::Debug,
| ^^^ there is a similarly named associated type `Bar` in the trait `Foo`
|
help: change the associated type name to use `Bar` from `Foo`
|
LL | T::Bar: std::fmt::Debug,
| ~~~
```
|
|
|
|
Hide host effect params from docs
addresses (only on nightly, needs backport) https://github.com/rust-lang/rust/issues/116629
r? `@compiler-errors`
cc `@GuillaumeGomez` `@fee1-dead`
|
|
|
|
On type error involving closure, avoid ICE
When we encounter a type error involving a closure, we try to typeck prior closure invocations to see if they influenced the current expected type. When trying to do so, ensure that the closure was defined in our current scope.
Fix #116658.
|
|
|
|
|
|
Improve check-cfg diagnostics
This PR tries to improve some of the diagnostics of check-cfg.
The main changes is the unexpected name or value being added to the main diagnostic:
```diff
- warning: unexpected `cfg` condition name
+ warning: unexpected `cfg` condition name: `widnows`
```
It also cherry-pick the better sensible logic for when we print the list of expected values when we have a matching value for a very similar name.
Address https://github.com/rust-lang/rust/pull/111072#discussion_r1356818100
r? `@petrochenkov`
|
|
|
|
When we encounter a type error involving a closure, we try to typeck
prior closure invocations to see if they influenced the current expected
type. When trying to do so, ensure that the closure was defined in our
current scope.
Fix #116658.
|
|
When parsing a closure without a body that is surrounded by a block,
suggest moving the opening brace after the closure head.
Fix #116608.
|
|
exhaustiveness: Rework constructor splitting
`SplitWildcard` was pretty opaque. I replaced it with a more legible abstraction: `ConstructorSet` represents the set of constructors for patterns of a given type. This clarifies responsibilities: `ConstructorSet` handles one clear task, and diagnostic-related shenanigans can be done separately.
I'm quite excited, I had has this in mind for years but could never quite introduce it. This opens up possibilities, including type-specific optimisations (like using a `FxHashSet` to collect enum variants, which had been [hackily attempted some years ago](https://github.com/rust-lang/rust/pull/76918)), my one-pass rewrite (https://github.com/rust-lang/rust/pull/116042), and future librarification.
|
|
Copy 1-element arrays as scalars, not vectors
For `[T; 1]` it's silly to copy as `<1 x T>` when we can just copy as `T`.
Inspired by https://github.com/rust-lang/rust/issues/101210#issuecomment-1732470941, which pointed out that `Option<[u8; 1]>` was codegenning worse than `Option<u8>`.
(I'm not sure *why* LLVM doesn't optimize out `<1 x u8>`, but might as well just not emit it in the first place in this codepath.)
---
I think I bit off too much in #116479; let me try just the scalar case first.
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=compiler-errors
Handle several `#[diagnostic::on_unimplemented]` attributes correctly
This PR fixes an issues where rustc would ignore subsequent `#[diagnostic::on_unimplemented]` attributes. The [corresponding RFC](https://rust-lang.github.io/rfcs/3368-diagnostic-attribute-namespace.html) specifies that the first matching instance of each option is used. Invalid attributes are linted and otherwise ignored.
|
|
|
|
|
|
Token cleanups
Some precursors to #114571 that are worth merging even if the main part of #114571 doesn't get merged.
r? `@petrochenkov`
|
|
Show enum discriminant if a compatible repr is used
Follow-up of #116142.
It was mentioned in the [team meeting](https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.2002-10-2023/near/394504024) that an enum with a `repr` should also get its discriminants displayed. Forgot to implement it in #116142...
It also allowed to uncover a bug: i was not providing the correct `DefId` in case it was a type alias to `render_enum_fields`. It's also fixed in this PR.
r? `@fmease`
|
|
Use structured suggestion for #113174
When encountering a for loop that is rejected by the borrow checker because it is being advanced within its body, provide a structured suggestion for `while let Some(pat) = iter.next()`.
|
|
Explaining something in the output that surprised me.
|
|
|
|
This PR fixes an issues where rustc would ignore subsequent
`#[diagnostic::on_unimplemented]` attributes. The [corresponding
RFC](https://rust-lang.github.io/rfcs/3368-diagnostic-attribute-namespace.html)
specifies that the first matching instance of each option is used.
Invalid attributes are linted and otherwise ignored.
|
|
|
|
Fix #72634.
|
|
When encountering a for loop that is rejected by the borrow checker
because it is being advanced within its body, provide a structured
suggestion for `while let Some(pat) = iter.next()`.
|
|
Prevent showing methods from blanket impls of not available foreign traits to show up in the search results
Fixes https://github.com/rust-lang/rust/issues/115480.
In the case that the blanket impl trait is not available in the current crate, we prevent adding its methods in the search index.
Now how I found how to fix the issue: the `equivalent` method is not generated in the documentation pages but was still added to the search index. To render impls, we iterate over `cache.impls` so I took a look at how this was generated. Inside `formats/cache.rs`, we have `CacheBuilder::populate` where we push impls into `impls` but with this condition:
```rust
if cx.cache.traits.contains_key(&trait_did) {
```
I re-used this condition in `CacheBuilder::fold_item` to prevent this method from being added in `cache.search_index` or `cache.orphan_impl_items`.
PS: If you want to double-check if the added test works, just comment the code I added in `cache.rs` and it should fail.
r? ``@notriddle``
|
|
compiler-errors:structurally-normalize-for-closure, r=lcnr
Structurally normalize for closure
Fixes some signature deduction problems in the new trait solver (and in the case of async, an ICE).
r? lcnr
|
|
Relate alias ty with variance
In the new solver, turns out that the subst-relate branch of the alias-relate predicate was relating args invariantly even for opaques, which have variance :skull:.
This change is a bit more invasive, but I'd rather not special-case it [here](https://github.com/rust-lang/rust/blob/aeaa5c30e5c9041264a2e8314b68ad84c2dc3169/compiler/rustc_trait_selection/src/solve/alias_relate.rs#L171-L190) and then have it break elsewhere. I'm doing a perf run to see if the extra call to `def_kind` is that expensive, if it is, I'll reconsider.
r? ``@lcnr``
|
|
|
|
|
|
Prevent spurious `unreachable pattern` lints
But it means we'll get more `non-exhaustive` patterns
fixes https://github.com/rust-lang/rust/issues/78057
r? `@Nadrieril` `@RalfJung`
|
|
|
|
Means you'll get more `non-exhaustive` patterns
|
|
Implement `-Clink-self-contained=-linker` opt out
This implements the `-Clink-self-contained` opt out necessary to switch to lld by changing rustc's defaults instead of cargo's.
Components that are enabled and disabled on the CLI are recorded, for the purpose of being merged with the ones which the target spec will declare (I'll open another PR for that tomorrow, for easier review).
For MCP510, we now check whether using the self-contained linker is disabled on the CLI. Right now it would only be sensible to with `-Zgcc-ld=lld` (and I'll add some checks that we don't both enable and disable a component on the CLI in a future PR), but the goal is to simplify adding the check of the target's enabled components here in the follow-up PRs.
r? `@petrochenkov`
|
|
Fix overflow checking in range patterns
When a range pattern contains an overflowing literal, if we're not careful we might not notice the overflow and use the wrapped value. This makes for confusing error messages because linting against overflowing literals is only done in a later pass. So when a range is invalid we check for overflows to provide a better error.
This check didn't use to handle negative types; this PR fixes that. First commit adds tests, second cleans up without changing behavior, third does the fix.
EDIT: while I was at it, I fixed a small annoyance about the span of the overflow lint on negated literals.
Fixes https://github.com/rust-lang/rust/issues/94239
|
