| Age | Commit message (Collapse) | Author | Lines |
|
|
|
* Add a new method `has_infer_types_or_consts` that's used instead most
of the time, since there's generally no reason to only consider types.
* Remove use of `has_closure_types`, because closures are no longer
implicitly linked to the `InferCtxt`.
|
|
|
|
|
|
|
|
Update tests
Extend to other operations
Refractor check in a separate function
Fix more tests
|
|
|
|
Same idea for `Unsafety` & use new span for better diagnostics.
|
|
Relax bounds on HashMap/HashSet
These APIs changed from the old bound listed to the new bound (possibly empty):
K: Hash + Eq -> K
* new
* with_capacity
K: Eq + Hash, S: BuildHasher -> K, S
* with_hasher
* with_capacity_and_hasher
* hasher
K: Eq + Hash + Debug -> K: Debug
S: BuildHasher -> S
HashMap as Debug
K: Eq + Hash -> K
S: BuildHasher + Default -> S: Default
HashMap as Default
Resolves #44777.
|
|
Make issue references consistent
Fixes https://github.com/rust-lang/rust/issues/62976
cc https://github.com/rust-lang/rust/pull/63008
r? @varkor because you reviewed the original pr
|
|
|
|
|
|
|
|
|
|
Address inconsistency in using "is" with "declared here"
"is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout.
r? @Centril
|
|
|
|
|
|
`TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.
|
|
Add regression test for integer literals in generic arguments in where clauses
Closes https://github.com/rust-lang/rust/issues/67753.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This error may be produced during intermediate failed attempts at evaluation of a generic const, which may nevertheless succeed later.
|
|
No functional changes are made, and all APIs are moved to strictly less
restrictive bounds.
These APIs changed from the old bound listed to the new bound:
T: Hash + Eq -> T
* new
* with_capacity
T: Eq + Hash, S: BuildHasher -> T
* with_hasher
* with_capacity_and_hasher
* hasher
T: Eq + Hash + Debug -> T: Debug
S: BuildHasher -> S
<HashSet as Debug>
T: Eq + Hash -> T
S: BuildHasher + Default -> S: Default
<HashSet as Default>
|
|
Add regression tests for fixed ICEs
Closes #61747 (fixed from 1.41.0-nightly (4007d4ef2 2019-12-01))
Closes #66205 (fixed from 1.41.0-nightly (4007d4ef2 2019-12-01))
Closes #66270 (fixed by #66246)
Closes #67424 (fixed by #67160)
Also picking a minor nit up from #67071 with 101dd7bad9432730fa2f625ae43afcc2929457d4
r? @Centril
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
This purges uses of uninitialized where possible from test cases. Some
are merely moved over to the equally bad pattern of
MaybeUninit::uninit().assume_init() but with an annotation that this is
"the best we can do".
|
|
|
|
|
|
Fix pointing at arg when cause is outside of call
Follow up after: #66933
Closes: #66923
r? @estebank
|
|
|
|
|
|
|
|
Highlight parts of fn in type errors
When a type error arises between two fn items, fn pointers or tuples,
highlight only the differing parts of each.
Examples:
<img width="699" alt="" src="https://user-images.githubusercontent.com/1606434/69487597-ab561600-0e11-11ea-9b4e-d4fd9e91d5dc.png">
<img width="528" alt="" src="https://user-images.githubusercontent.com/1606434/69487207-9033d800-0e0a-11ea-93e3-8c4d002411a5.png">
<img width="468" alt="" src="https://user-images.githubusercontent.com/1606434/69487208-9033d800-0e0a-11ea-92e3-2b2cee120335.png">
<img width="775" alt="" src="https://user-images.githubusercontent.com/1606434/69487209-9033d800-0e0a-11ea-9e68-7f6ed5c8cb08.png">
|
|
When a type error arises between two fn items, fn pointers or tuples,
highlight only the differing parts of each.
|
|
|
|
Specific labels when referring to "expected" and "found" types
|
|
Braces were left in cases where generic args were in the generic const
paths.
|
|
|
|
|
|
|
|
|
|
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Fixes #56277
|
|
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
|
|
This reverts commit 49cbfa1a6f6469ddbc0e88161e52104cc87aea9b.
|
|
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
|