| Age | Commit message (Collapse) | Author | Lines |
|---|
|
use the adjusted type for cat_pattern in tuple patterns
This looks like a typo introduced in #51686.
Fixes #52213.
r? @pnkfelix
beta + stable nominating because regression + unsoundness.
|
|
This looks like a typo introduced in #51686.
Fixes #52213.
|
|
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
|
|
Fix various issues with control-flow statements inside anonymous constants
Fixes #51761.
Fixes #51963 (and the host of other reported issues there).
(Might be easiest to review per commit, as they should be standalone.)
r? @estebank
|
|
Get rid of `TyImplTraitExistential`
cc @eddyb
r? @nikomatsakis
|
|
|
|
|
|
(The present author fears not being knowledgeable enough to rewrite the
comments unilaterally; merely calling it out is a lazy half-measure, but
at least doesn't actively make things worse the way an ill-informed
rewrite would.)
|
|
For the HirIdification initiative #50928.
|
|
r=petrochenkov
add modifier keyword spans to hir::Visibility; improve unreachable-pub, private-no-mangle lint suggestions
#50455 pointed out that the unreachable-pub suggestion for brace-grouped `use`s was bogus; #50476 partially ameliorated this by marking the suggestion as `Applicability::MaybeIncorrect`, but this is the actual fix.
Meanwhile, another application of having spans available in `hir::Visibility` is found in the private-no-mangle lints, where we can now issue a suggestion to use `pub` if the item has a more restricted visibility marker (this seems much less likely to come up in practice than not having any visibility keyword at all, but thoroughness is a virtue). While we're there, we can also add a helpful note if the item does have a `pub` (but triggered the lint presumably because enclosing modules were private).
r? @nrc
cc @Manishearth
|
|
improve the error message when `#[panic_implementation]` is missing
closes #51341
r? @nagisa
cc @phil-opp
|
|
Always check type_dependent_defs
Directly indexing into `type_dependent_defs` has caused multiple ICEs in the past (https://github.com/rust-lang/rust/issues/46771, https://github.com/rust-lang/rust/issues/49241, etc.) and is almost certainly responsible for #51798 too. This PR ensures we always check `type_dependent_defs` first, which should prevent any more of these (or at least make them easier to track down).
|
|
There are at least a couple (and plausibly even three) diagnostics that
could use the spans of visibility modifiers in order to be reliably
correct (rather than hacking and munging surrounding spans to try to
infer where the visibility keyword must have been).
We follow the naming convention established by the other `Spanned` HIR
nodes: the "outer" type alias gets the "prime" node-type name, the
"inner" enum gets the name suffixed with an underscore, and the variant
names are prefixed with the prime name and `pub use` exported from here
(from HIR).
Thanks to veteran reviewer Vadim Petrochenkov for suggesting this
uniform approach. (A previous draft, based on the reasoning that
`Visibility::Inherited` should not have a span, tried to hack in a named
`span` field on `Visibility::Restricted` and a positional field on
`Public` and `Crate`. This was ... not so uniform.)
|
|
|
|
closes #51341
|
|
Refactor error reporting of constants
cc @eddyb
This PR should not change any behaviour. It solely simplifies the internal handling of the errors
|
|
|
|
translate / export weak lang items
see #51671 for details
fixes #51671
fixes #51342
r? @michaelwoerister or @alexcrichton
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove emulation of hygiene with gensyms
|
|
Namely: labels, type parameters, bindings in patterns, parameter names in functions without body.
All of these do not need hygiene after lowering to HIR, only span locations.
|
|
|
|
Suggestion for 'static impl Trait return
When encountering a named or anonymous sup requirement (for example,
`&'a self`) and a `'static` impl Trait return type, suggest adding the
`'_` lifetime constraing to the return type.
Fix #43719, #51282.
```
error: cannot infer an appropriate lifetime
--> $DIR/static-return-lifetime-infered.rs:17:16
|
LL | fn iter_values_anon(&self) -> impl Iterator<Item=u32> {
| ----------------------- this return type evaluates to the `'static` lifetime...
LL | self.x.iter().map(|a| a.0)
| ------ ^^^^
| |
| ...but this borrow...
|
note: ...can't outlive the anonymous lifetime #1 defined on the method body at 16:5
--> $DIR/static-return-lifetime-infered.rs:16:5
|
LL | / fn iter_values_anon(&self) -> impl Iterator<Item=u32> {
LL | | self.x.iter().map(|a| a.0)
LL | | }
| |_____^
help: you can add a constraint to the return type to make it last less than `'static` and match the anonymous lifetime #1 defined on the method body at 16:5
|
LL | fn iter_values_anon(&self) -> impl Iterator<Item=u32> + '_ {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
|
|
|
|
Recently, there has been some rearrangement of the content in the Rustc
Guide, and this commit changes the urls the match the updated guide.
|
|
Rename hir::ExprAgain to hir::ExprContinue
The current name is confusing and historical.
I also used this PR to clean up the annoying indentation in `check/mod.rs`. If that's viewed as too tangential a change, I'll split it up, but it seemed reasonable to slip it in to reduce @bors's work. It's easy to compare for the two commits individually.
r? @petrochenkov
|
|
|
|
async/await
This PR implements `async`/`await` syntax for `async fn` in Rust 2015 and `async` closures and `async` blocks in Rust 2018 (tracking issue: https://github.com/rust-lang/rust/issues/50547). Limitations: non-`move` async closures with arguments are currently not supported, nor are `async fn` with multiple different input lifetimes. These limitations are not fundamental and will be removed in the future, however I'd like to go ahead and get this PR merged so we can start experimenting with this in combination with futures 0.3.
Based on https://github.com/rust-lang/rust/pull/51414.
cc @petrochenkov for parsing changes.
r? @eddyb
|
|
Add label to lint for lifetimes used once
```
error: lifetime parameter `'a` only used once
--> $DIR/fn-types.rs:19:10
|
LL | a: for<'a> fn(&'a u32), //~ ERROR `'a` only used once
| ^^ -- ...is used only here
| |
| this lifetime...
```
|
|
r=petrochenkov
Support future deprecation for rustc_deprecated
Follow-up to #49179 to allow `since` parameters to be set to future versions of Rust and correspondingly to not be treated as deprecated until that version. This is required for #30459 to be completed (though we'll need to wait until this hits beta).
|
|
nikomatsakis:issue-51415-borrowck-match-default-bindings-bug, r=eddyb
yet another "old borrowck" bug around match default bindings
We were getting the type of the parameter from its pattern, but that didn't include adjustments. I did a `ripgrep` around and this seemed to be the only affected case.
The reason this didn't show up as an ICE earlier is that mem-categorization is lenient with respect to weird discrepancies. I am going to add more delay-span-bug calls shortly around that (I'll push onto the PR).
This example is an ICE, but I presume that there is a way to make a soundness example out of this -- it basically ignores borrows occuring inside match-default-bindings in a closure, though only if the implicit deref is at the top-level. It happens though that this occurs frequently in iterators, which often give a `&T` parameter.
Fixes #51415
Fixes #49534
r? @eddyb
|
|
This is gated on edition 2018 & the `async_await` feature gate.
The parser will accept `async fn` and `async unsafe fn` as fn
items. Along the same lines as `const fn`, only `async unsafe fn`
is permitted, not `unsafe async fn`.The parser will not accept
`async` functions as trait methods.
To do a little code clean up, four fields of the function type
struct have been merged into the new `FnHeader` struct: constness,
asyncness, unsafety, and ABI.
Also, a small bug in HIR printing is fixed: it previously printed
`const unsafe fn` as `unsafe const fn`, which is grammatically
incorrect.
|
|
|
|
do not ICE when existing type info is incomplete
Apparently master is kinda ICE-y right now, but only for some people (sadly that set includes me).
I'm not crazy about this PR, because it seems to regress diagnostics a lot, but it *does* fix the problems. I think probably fixing the diagnostics should be done by doing a better job of suppressing errors?
Mitigates #51683
r? @oli-obk
|
|
|
|
|
|
|
|
see #51671 for details
fixes #51671
fixes #51342
|
|
|
|
|
|
|
|
|
|
|
|
|
