| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This commit checks that the target type of the cast (an error related
to which is being reported) does not have types to be inferred before
checking if it implements the `From` trait.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Fix #74081 and add the test case from #74236
|
|
|
|
Only allow `repr(i128/u128)` on enum
Fixes #74082
|
|
Other terms are more inclusive and precise.
Clippy still has a lint named "blacklisted-name", but renaming it would
be a breaking change, so is left for future work.
The target configuration option "abi-blacklist" has been depreciated and
renamed to "unsupported-abis". The old name continues to work.
|
|
Audit hidden/short code suggestions
Should fix #73641.
Audit uses of `span_suggestion_short` and `tool_only_span_suggestion` (`span_suggestion_hidden` is already tested with `run-rustfix`). Leave some FIXMEs for futher improvements/fixes.
r? @estebank
|
|
|
|
Fix try_print_visible_def_path for Rust 2018
The recursive check of `try_print_visible_def_path` did not properly handle the Rust 2018 case of crate-paths without 'extern crate'. Instead, it returned a "not found" via (false, self).
This fixes #56175.
|
|
This commit modifies resolve to disallow `break`/`continue` to labels
through closures or async blocks. This doesn't make sense and should
have been prohibited anyway.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
The recursive check of `try_print_visible_def_path` did not properly handle
the Rust 2018 case of crate-paths without 'extern crate'. Instead, it returned
a "not found" via (false, self).
This fixes issue #56175.
|
|
|
|
Stabilize `#![feature(const_if_match)]`
Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045):
> `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following:
>
> - The initializer of a `const`, `static`, `static mut` or enum discriminant.
> - The body of a `const fn`.
> - The value of a const generic (nightly only).
> - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`).
>
> Furthermore, the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result, `let` bindings can be used alongside short-circuiting logic in those initializers.
Resolves #49146.
Ideally, we would resolve :whale: #66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative `const fn`.
r? @oli-obk
|
|
|
|
|
|
r=petrochenkov
Rename clashing_extern_decl to clashing_extern_declarations.
Rename clashing_extern_decl to clashing_extern_declarations to bring in-line with lint naming conventions.
Fixes #73802.
r? @petrochenkov
|
|
Explain move errors that occur due to method calls involving `self` (take two)
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
|
|
Also, run RustFmt on the clashing_extern_fn test case and update
stderrs.
|
|
Perform obligation deduplication to avoid buggy `ExistentialMismatch`
Address #59326.
|
|
This is a re-attempt of #72389 (which was reverted in #73594)
Instead of using `ExpnKind::Desugaring` to represent operators, this PR
checks the lang item directly.
|
|
propagation
|
|
Tweak binop errors
* Suggest potentially missing binop trait bound (fix #73416)
* Use structured suggestion for dereference in binop
|
|
Verify that the binop trait *is* implemented for the types *if* all the
involved type parameters are replaced with fresh inferred types. When
this is the case, it means that the type parameter was indeed missing a
trait bound. If this is not the case, provide a generic `note` refering
to the type that doesn't implement the expected trait.
|
|
* deduplicate logic
* fix typos
* remove unnecessary state
|
|
This commit adds a new lint - `improper_ctypes_definitions` - which
functions identically to `improper_ctypes`, but on `extern "C" fn`
definitions (as opposed to `improper_ctypes`'s `extern "C" {}`
declarations).
Signed-off-by: David Wood <david@davidtw.co>
|
|
* Suggest potentially missing binop trait bound (fix #73416)
* Use structured suggestion for dereference in binop
|
|
r=ecstatic-morse
Point at the call span when overflow occurs during monomorphization
This improves the output for issue #72577, but there's still more work
to be done.
Currently, an overflow error during monomorphization results in an error
that points at the function we were unable to monomorphize. However, we
don't point at the call that caused the monomorphization to happen. In
the overflow occurs in a large recursive function, it may be difficult
to determine where the issue is.
This commit tracks and `Span` information during collection of
`MonoItem`s, which is used when emitting an overflow error. `MonoItem`
itself is unchanged, so this only affects
`src/librustc_mir/monomorphize/collector.rs`
|
|
A way forward for pointer equality in const eval
r? @varkor on the first commit and @RalfJung on the second commit
cc #53020
|
|
move leak-check to during coherence, candidate eval
Implementation of MCP https://github.com/rust-lang/compiler-team/issues/295.
I'd like to do a crater run on this.
Note to @rust-lang/lang: This PR is a breaking change (bugfix). It causes tests like the following to go from a future-compatibility warning #56105 to a hard error:
```rust
trait Trait {}
impl Trait for for<'a, 'b> fn(&'a u32, &'b u32) {}
impl Trait for for<'c> fn(&'c u32, &'c u32) {} // now rejected, used to warn
```
I am not aware of any instances of this code in the wild, but that is why we are doing a crater run. The reason for this change is that those two types are, in fact, the same type, and hence the two impls are overlapping.
There will still be impls that trigger #56105 after this lands, however -- I hope that we will eventually just accept those impls without warning, for the most part. One example of such an impl is this pattern, which is used by wasm-bindgen and other crates as well:
```rust
trait Trait {}
impl<T> Trait for fn(&T) { }
impl<T> Trait for fn(T) { } // still accepted, but warns
```
|
|
The bug was revealed by the behavior of the old-lub-glb-hr-noteq1.rs
test. The old-lub-glb-hr-noteq2 test shows the current 'order dependent'
behavior of coercions around higher-ranked functions, at least when
running with `-Zborrowck=mir`.
Also, run compare-mode=nll.
|
|
Motivation:
- we want to use leak-check sparingly, first off
- these calls were essentially the same as doing the check during subtyping
|
|
This improves the output for issue #72577, but there's still more work
to be done.
Currently, an overflow error during monomorphization results in an error
that points at the function we were unable to monomorphize. However, we
don't point at the call that caused the monomorphization to happen. In
the overflow occurs in a large recursive function, it may be difficult
to determine where the issue is.
This commit tracks and `Span` information during collection of
`MonoItem`s, which is used when emitting an overflow error. `MonoItem`
itself is unchanged, so this only affects
`src/librustc_mir/monomorphize/collector.rs`
|
|
r=nikomatsakis"
This reverts commit 372cb9b69c76a042d0b9d4b48ff6084f64c84a2c, reversing
changes made to 5c61a8dc34c3e2fc6d7f02cb288c350f0233f944.
|
|
In particular, it no longer occurs during the subtyping check. This is
important for enabling lazy normalization, because the subtyping check
will be producing sub-obligations that could affect its results.
Consider an example like
for<'a> fn(<&'a as Mirror>::Item) =
fn(&'b u8)
where `<T as Mirror>::Item = T` for all `T`. We will wish to produce a
new subobligation like
<'!1 as Mirror>::Item = &'b u8
This will, after being solved, ultimately yield a constraint that `'!1
= 'b` which will fail. But with the leak-check being performed on
subtyping, there is no opportunity to normalize `<'!1 as
Mirror>::Item` (unless we invoke that normalization directly from
within subtyping, and I would prefer that subtyping and unification
are distinct operations rather than part of the trait solving stack).
The reason to keep the leak check during coherence and trait
evaluation is partly for backwards compatibility. The coherence change
permits impls for `fn(T)` and `fn(&T)` to co-exist, and the trait
evaluation change means that we can distinguish those two cases
without ambiguity errors. It also avoids recreating #57639, where we
were incorrectly choosing a where clause that would have failed the
leak check over the impl which succeeds.
The other reason to keep the leak check in those places is that I
think it is actually close to the model we want. To the point, I think
the trait solver ought to have the job of "breaking down"
higher-ranked region obligation like ``!1: '2` into into region
obligations that operate on things in the root universe, at which
point they should be handed off to polonius. The leak check isn't
*really* doing that -- these obligations are still handed to the
region solver to process -- but if/when we do adopt that model, the
decision to pass/fail would be happening in roughly this part of the
code.
This change had somewhat more side-effects than I anticipated. It
seems like there are cases where the leak-check was not being enforced
during method proving and trait selection. I haven't quite tracked
this down but I think it ought to be documented, so that we know what
precisely we are committing to.
One surprising test was `issue-30786.rs`. The behavior there seems a
bit "fishy" to me, but the problem is not related to the leak check
change as far as I can tell, but more to do with the closure signature
inference code and perhaps the associated type projection, which
together seem to be conspiring to produce an unexpected
signature. Nonetheless, it is an example of where changing the
leak-check can have some unexpected consequences: we're now failing to
resolve a method earlier than we were, which suggests we might change
some method resolutions that would have been ambiguous to be
successful.
TODO:
* figure out remainig test failures
* add new coherence tests for the patterns we ARE disallowing
|
|
This reverts commit 2e01db4b396a1e161f7a73933fff34bc9421dba0.
|
|
Also, update the affected tests. This seems strictly better but it is
actually more permissive than I initially intended. In particular it
accepts this
```
forall<'a, 'b> {
exists<'intersection> {
'a: 'intersection,
'b: 'intersection,
}
}
```
and I'm not sure I want to accept that. It implies that we have a
`'empty` in the new universe intoduced by the `forall`.
|
|
Add E0765
|
|
Prefer accessible paths in 'use' suggestions
This PR addresses issue https://github.com/rust-lang/rust/issues/26454, where `use` suggestions are made for paths that don't work. For example:
```rust
mod foo {
mod bar {
struct X;
}
}
fn main() { X; } // suggests `use foo::bar::X;`
```
|
|
This fixes an issue with the following sample:
mod foo {
mod inaccessible {
pub struct X;
}
pub mod avail {
pub struct X;
}
}
fn main() { X; }
Instead of suggesting both `use crate::foo::inaccessible::X;` and `use
crate::foo::avail::X;`, it should only suggest the latter.
It is done by trimming the list of suggestions from inaccessible paths
if accessible paths are present.
Visibility is checked with `is_accessible_from` now instead of being
hard-coded.
-
Some tests fixes are trivial, and others require a bit more explaining,
here are my comments:
src/test/ui/issues/issue-35675.stderr: Only needs to make the enum
public to have the suggestion make sense.
src/test/ui/issues/issue-42944.stderr: Importing the tuple struct won't
help because its constructor is not visible, so the attempted
constructor does not work. In that case, it's better not to suggest it.
The case where the constructor is public is covered in `issue-26545.rs`.
|
|
|
|
Add a lint to catch clashing `extern` fn declarations.
Closes #69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
r? @eddyb
|
|
Given `trait X { type U; }` the bound `<Self as X>::U` now lives
on the type, rather than the trait. This is feature gated on
`feature(generic_associated_types)` for now until more testing can
be done.
The also enabled type-generic associated types since we no longer
need "implies bounds".
|
|
This was currently only happening due to eager normalization, which
isn't possible if there's specialization or bound variables.
|
|
everything in the diagnostic
|
|
- Allow ClashingExternDecl for lint-dead-code-3
- Update test case for #5791
- Update test case for #1866
- Update extern-abi-from-macro test case
|
|
Unify region variables when projecting associated types
This is required to avoid cycles when evaluating auto trait predicates.
Notably, this is required to be able add Chalk types to `CtxtInterners` for `cfg(parallel_compiler)`.
r? @nikomatsakis
|
|
Make `need_type_info_err` more conservative
Makes sure arg patterns we are going to suggest on are actually contained within the span of the obligation that caused the inference error (credit to @lcnr for suggesting this fix).
There's a subtle trade-off regarding the handling of local patterns which I've left a comment about.
Resolves #72690
|
|
forbid mutable references in all constant contexts except for const-fns
PR to address #71212
cc: @ecstatic-morse
|
|
Specialization is unsound
As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949, it might be a good idea to warn users of specialization that the feature they are using is unsound.
I also expanded the "incomplete feature" warning to link the user to the tracking issue.
|
