| Age | Commit message (Collapse) | Author | Lines |
|
Make use of possibly uninitialized data [E0381] a hard error
This is one of the behaviors we no longer allow in NLL. Since it can
lead to undefined behavior, I think it's definitely worth making it a
hard error without waiting to turn off migration mode (#58781).
Closes #60450.
My ulterior motive here is making it impossible to leave variables
partially initialized across a yield (see #60889, discussion at #63035), so
tests are included for that.
cc #54987
---
I'm not sure if bypassing the buffer is a good way of doing this. We could also make a `force_errors_buffer` or similar that gets recombined with all the errors as they are emitted. But this is simpler and seems fine to me.
r? @Centril
cc @cramertj @nikomatsakis @pnkfelix @RalfJung
|
|
This is one of the behaviors we no longer allow in NLL. Since it can
lead to undefined behavior, I think it's definitely worth making it a
hard error without waiting to turn off migration mode (#58781).
Closes #60450.
My ulterior motive here is making it impossible to leave variables
partially initialized across a yield (see discussion at #63035), so
tests are included for that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement built-in await syntax
Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.
This new syntax is not final, but is the consensus solution proposed by the lang team, as explained in https://boats.gitlab.io/blog/post/await-decision/
Fix https://github.com/rust-lang/rust/issues/51719
Fix https://github.com/rust-lang/rust/issues/51751
Fix https://github.com/rust-lang/rust/issues/60016
|
|
Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.
|
|
This commit extends the logic used to determine what the expected
signature of a closure is so that it can also determine the expected
signature of a generator. This improves a diagnostic where the fn
signature was blamed instead of the generator body. It doesn't fix
fix the diagnostic for `async fn`.
|
|
This commit adds a test for the current behaviour of signature deduction
of generators when there is a type mismatch between the return type of
the function body and the signature.
|
|
|
|
Improved error message when type must be bound due to generator.
Fixes #58930.
Keen to get some feedback - is this as minimal as we can get it or is there an existing visitor I could repurpose?
|
|
Error now mentions type var name and span is highlighted.
|
|
|
|
|
|
|
|
ignore higher-ranked object bound conditions created by WF
In the `issue-53548` test added in this PR, the `Box<dyn Trait>` type is expanded to `Box<dyn Trait + 'static>`, but the generator "witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF code was encountering an ICE (when debug-assertions were enabled) and an unexpected compilation error (without debug-asserions) when trying to process this `'r` region bound. In particular, to be WF, the region bound must meet the requirements of the trait, and hence we got `for<'r> { 'r: 'static }`. This would ICE because the `Binder` constructor we were using was assering that no higher-ranked regions were involved (because the WF code is supposed to skip those). The error (if debug-asserions were disabled) came because we obviously cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to require that `for<'r> { 'r: 'static }` holds (this is also analogous to what we would do for higher-ranked regions appearing within the trait in other positions).
Fixes #53548
r? @pnkfelix
|
|
In the `issue-53548` test added in this commit, the `Box<dyn Trait>`
type is expanded to `Box<dyn Trait + 'static>`, but the generator
"witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF
code was encountering an ICE (when debug-assertions were enabled) and
an unexpected compilation error (without debug-asserions) when trying
to process this `'r` region bound. In particular, to be WF, the region
bound must meet the requirements of the trait, and hence we got
`for<'r> { 'r: 'static }`. This would ICE because the `Binder`
constructor we were using was assering that no higher-ranked regions
were involved (because the WF code is supposed to skip those). The
error (if debug-asserions were disabled) came because we obviously
cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to
require that `for<'r> { 'r: 'static }` holds (this is also analogous
to what we would do for higher-ranked regions appearing within the
trait in other positions).
|
|
|
|
|
|
Add information to higher-ranked lifetimes conflicts error messages
Make these errors go through the new "placeholder error" code path, to have self tys displayed and make them hopefully less confusing.
Should fix #57362.
r? @nikomatsakis — so we can iterate on the specific wording you wanted.
|
|
than "the specific lifetime"
|
|
|
|
|
|
|
|
|
|
Fix broken links to second edition TRPL.
Fixes https://github.com/rust-lang/rust/issues/57104.
Remove `second-edition/` from TRPL hyperlinks.
|
|
In particular, when we want to indicate that there is a connection
between the self type and the other types.
|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/57104.
|
|
|
|
Refer to the second borrow as the "second borrow" in E0501.rs
Fixes #55314.
r? @davidtwco
|
|
|
|
|
|
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value
referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure
to a captured variable.
|
|
r=nikomatsakis
[NLL] Propagate bounds from generators
This used to only be done for closures.
|
|
|
|
This commit extends existing special-casing of closures to highlight the
use of variables within generators that are causing the generator to
borrow them.
|
|
|
|
Give a special message when the later use is from a call. Use the span
of the callee instead of the whole expression. For conflicting borrow
messages say that the later use is of the first borrow.
|
|
|
|
|
|
Similar to #52404. The link for comparison:
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-sized (broken)
- https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait (correct, stable 2nd ed)
- https://doc.rust-lang.org/nightly/book/second-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait (correct, nightly 2nd ed)
- https://doc.rust-lang.org/nightly/book/2018-edition/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait (correct, nightly 2018 ed)
This commit is the result of (first) searching via ripgrep (0.8.1 -SIMD -AVX):
rg -l dynamically-sized-types-and-sized
and then replacing all relevant occurrences via:
find src/{libcore,test/ui} -type f -print0 | xargs -0 sed -i.bak \
s/dynamically-sized-types-and-sized/dynamically-sized-types-and-the-sized-trait/g
find src/{libcore,test/ui} -type f -name '*.bak' -print0 | xargs -0 rm
(Note: Tested on on macOS 10.13 (BSD). `sed -i.bak` should work on Linux
(GNU sed) as well, but not tested.)
|
|
(Presumably the place that borrow_check ends up reporting for the
error about is no longer the root `Local` itself, and thus the note
diagnostic here stops firing.)
|