| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Properly enforce the "patterns aren't allowed in foreign functions" rule
Cases like `arg @ PATTERN` or `mut arg` were missing.
Apply the same rule to function pointer types.
Closes https://github.com/rust-lang/rust/issues/35203
[breaking-change], no breakage in sane code is expected though
r? @nikomatsakis
This is somewhat related to https://github.com/rust-lang/rfcs/pull/1685 (cc @matklad).
The goal is to eventually support full pattern syntax where it makes sense (function body may present) and to support *only* the following forms - `TYPE`, `ident: TYPE`, `_: TYPE` - where patterns don't make sense (function body doesn't present), i.e. in foreign functions and function pointer types.
|
|
Automatically enable -Zorbit if -Zincremental is specified.
Fixes #34973
r? @nikomatsakis
|
|
Apply the same check to function pointer types
|
|
|
|
resolve: Avoid emitting an unhelpful cascading resolution error
Fixes #35142.
|
|
Methods `Fn(Mut,Once)::call(mut,once)` are gated with two feature gates, remove one of them
Methods `Fn::call`, `FnMut::call_mut` and `FnOnce::call_once` are gated with usual library feature `fn_traits` and also hardcoded in the compiler and gated once more with feature `unboxed_closures`
This patch removes the `unboxed_closures`feature gate from these methods (`unboxed_closures` is still used for other things though), now they are gated only with `fn_traits`.
All unnecessary `#![feature(unboxed_closures)]`s are removed, many of them are old and were already unnecessary before the change this PR does.
|
|
Suppress unused type parameter error when type has error field
Fix #35075.
|
|
typeck: use a TypeVisitor in ctp
Use a TypeVisitor in ctp instead of `ty::walk`
This fixes a few cases where a region could be projected out of a trait while not being constrained by the type parameters, violating rust-lang/rfcs#447 and breaking soundness. As such, this is a [breaking-change].
Fixes #35139
r? @eddyb
|
|
|
|
|
|
Fixes #35139
|
|
Avoid writing a temporary closure kind
We used to write a temporary closure kind into the inference table, but
this could lead to obligations being incorrectled resolved before
inference had completed. This result could then be cached, leading to
further trouble. This patch avoids writing any closure kind until the
computation is complete.
Fixes #34349.
r? @arielb1 -- what do you think?
|
|
diagnostically note source of overruling outer forbid
When we emit E0453 (lint level attribute overruled by outer `forbid`
lint level), it could be helpful to note where the `forbid` level was
set, for the convenience of users who, e.g., believe that the correct
fix is to weaken the `forbid` to `deny`.
|
|
`unboxed_closures`
They are already gated with feature `fn_traits`
|
|
Properly feature gate all unstable ABIs
Fixes https://github.com/rust-lang/rust/issues/34900
[breaking-change]
r? @pnkfelix
---
Function-visiting machinery for AST/HIR is surprisingly error-prone, it's *very* easy to miss some cases or visit something twice while writing a visitor. This is the true problem behind https://github.com/rust-lang/rust/issues/34900. I'll try to restructure these visitors a bit and send one more PR later.
|
|
When we emit E0453 (lint level attribute overruled by outer `forbid`
lint level), it could be helpful to note where the `forbid` level was
set, for the convenience of users who, e.g., believe that the correct
fix is to weaken the `forbid` to `deny`.
|
|
|
|
syntax_ext: format: fix ICE with bad named arguments
Fixes #35082 by guarding against a new case of malformed invocation not previously covered.
r? @alexcrichton
|
|
r=nikomatsakis
Rename _ to {integer} and {float} for unknown numeric types
This PR renames _ to {integer} or {float} for unknown numeric types, to help people parse error messages that have numeric types that haven't been nailed down.
Example:
```rust
fn main() {
let x: String = 4;
}
```
Before:
```
error[E0308]: mismatched types
--> quicktest.rs:2:21
|
2 | let x: String = 4;
| ^ expected struct `std::string::String`, found integral variable
|
= note: expected type `std::string::String`
= note: found type `_`
error: aborting due to previous error
```
after:
```
error[E0308]: mismatched types
--> quicktest.rs:2:21
|
2 | let x: String = 4;
| ^ expected struct `std::string::String`, found integral variable
|
= note: expected type `std::string::String`
= note: found type `{integer}`
error: aborting due to previous error
```
```
|
|
resolve: Exclude inaccessible names from single imports
If a single import resolves to an inaccessible name in some but not all namespaces, avoid importing the name in the inaccessible namespaces.
Currently, the inaccessible namespaces are imported but cause a privacy error when used.
r? @nrc
|
|
|
|
|
|
|
|
resolve: Fix ICE and extra diagnostics happening when unresolved imports are used in patterns
Closes https://github.com/rust-lang/rust/issues/34933
r? @jseyfried
|
|
macros: Improve `tt` matchers
Fixes #5846, fixes #22819.
r? @nrc
|
|
|
|
Centralize and clean type error reporting
Refactors the code that handles type errors to be cleaner and fixes various edge cases.
This made the already-bad "type mismatch resolving" error message somewhat uglier. I want to fix that in another commit before this PR is merged.
Fixes #31173
r? @jonathandturner, cc @nikomatsakis
|
|
Avoid reseting the thread local interner at the beginning of `phase_1_parse_input`
The thread local interner is used before `phase_1_parse_input` to create `InternedString`s, which currently wrap `Rc<String>`s. Once `InternedString` is refactored to be an interned string id (like `Name`), resetting will invalidate everything that was interned before `phase_1_parse_input`.
The resets were only useful for the `rusti` project, which can now use `driver::reset_thread_local_state`.
r? @nrc
|
|
|
|
|
|
I split the RFC1592 commit out
|
|
We used to write a temporary closure kind into the inference table, but
this could lead to obligations being incorrectled resolved before
inference had completed. This result could then be cached, leading to
further trouble. This patch avoids writing any closure kind until the
computation is complete.
Fixes #34349.
|
|
The type equation in projection takes place under a binder and a snapshot, which
we can't easily take types out of. Instead, when encountering a projection error,
try to re-do the projection and find the type error then.
This fails to produce a sane type error when the failure was a "leak_check" failure.
I can't think of a sane way to show *these*, so I just left them use the old crappy
representation, and added a test to make sure we don't break them.
|
|
Refactor constant evaluation to use a single error reporting function
that reports a type-error-like message.
Also, unify all error codes with the "constant evaluation error" message
to just E0080, and similarly for a few other duplicate codes. The old
situation was a total mess, and now that we have *something* we can
further iterate on the UX.
|
|
Unfortunately, projection errors do not come with a nice set of
mismatched types. This is because the type equality check occurs
within a higher-ranked context. Therefore, only the type error
is reported. This is ugly but was always the situation.
I will introduce better errors for the lower-ranked case in
another commit.
Fixes the last known occurence of #31173
|
|
|
|
|
|
|
|
Add `is_empty` function to `ExactSizeIterator`
All other types implementing a `len` functions have `is_empty` already.
|
|
|
|
macros: fix bug in `stmt` matchers
Today, `stmt` matchers stop too early when parsing expression statements that begin with non-braced macro invocations. For example,
```rust
fn main() {
macro_rules! m { ($s:stmt;) => { $s } }
id!(vec![].push(0););
//^ Before this PR, the `stmt` matcher only consumes "vec![]", so this is an error.
//| After this PR, the `stmt` matcher consumes "vec![].push(0)", so this compiles.
}
```
This change is backwards compatible due to the follow set for `stmt`.
r? @eddyb
|
|
|
|
Do not resolve inherent static methods from other crates prematurely
Under some specific circumstances paths like `Type::method` can be resolved early in rustc_resolve instead of type checker. `Type` must be defined in another crate, it should be an enum or a trait object (i.e. a type that acts as a "module" in resolve), and `method` should be an inherent static method.
As a result, such paths don't go through `resolve_ufcs`, may be resolved incorrectly and break some invariants in type checker. This patch removes special treatment of such methods.
The removed code was introduced in https://github.com/rust-lang/rust/commit/2bd46e767c0fe5b6188df61cb9daf8f2e65a3ed0 to fix a problem that no longer exists.
r? @jseyfried
|
|
|
|
Variant Size Differences: Erase regions before computing type layout
Fixes #34839
|
|
Fix `include!()`s inside `asm!()` invocations
Fixes #34812, a regression caused by #33749 that was not fixed in #34450.
r? @nrc
|
|
Fixes #34839
|
|
|
|
Fixed issue where importing a trait method directly and then calling the method causes a compiler panic
The code below triggers the panic, and is included in a new regression test.
```rust
trait Foo {
fn foo();
}
use Foo::foo;
fn main() {
foo();
}
```
The bug is caused by `librustc_resolve` allowing the illegal binding to be imported even after displaying the error message above.
The fix amounts to importing a dummy binding (`rustc::hir::def::Def::Err`) instead of the actual trait method.
|
