| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rename C-like enum to Field-less enum
There is no need to reference the C programming language to explain this concept.
|
|
Point to next token when it is in the expected line
r? @nikomatsakis
|
|
Generic Associated Types Parsing & Name Resolution
Hi!
This PR adds parsing for generic associated types! :tada: :tada: :tada:
Tracking Issue: #44265
## Notes For Reviewers
* [x] I still need to add the stdout and stderr files to my ui tests. It takes me a *long* time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so.
* [ ] My current ui tests aren't very good or very thorough. I'm reusing the `parse_generics` and `parse_where_clause` methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases.
* [ ] There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear:
```
error[E0110]: lifetime parameters are not allowed on this type
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41
|
23 | bar: <T as StreamingIterator>::Item<'static>,
| ^^^^^^^ lifetime parameter not allowed on this type
```
```
error[E0261]: use of undeclared lifetime name `'a`
--> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47
|
15 | type Iter<'a>: Iterator<Item = Self::Item<'a>>;
| ^^ undeclared lifetime
```
There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following:
```
error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=`
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45
|
29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }
| ^ expected one of `!`, `+`, `,`, `::`, or `>` here
```
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
Account for missing keyword in fn/struct definition
Fix #38911.
|
|
This commit adds support for nested groups inside `use` declarations,
such as `use foo::{bar, sub::{baz::Foo, *}};`.
|
|
|
|
|
|
|
|
Added note that specifies a semicolon should be removed after a given struct
|
|
|
|
|
|
|
|
|
|
Try to identify the following code in order to provide better
diagnostics, but return the error to bail out early during the parse.
|
|
When encountering `pub ident`, attempt to identify the code that comes
afterwards, wether it is a brace block (assume it is a struct), a paren
list followed by a colon (assume struct) or a paren list followed by a
block (assume a fn). Consume those blocks to avoid any further parser
errors and return a `Placeholder` item in order to allow the parser to
continue. In the case of unenclosed blocks, the behavior is the same as
it is currently: no further errors are processed.
|
|
|
|
|
|
|
|
Remove some outdated messages from "no patterns allowed" errors
|
|
Add error for `...` in expressions
Follow-up to https://github.com/rust-lang/rust/pull/44709
Tracking issue: https://github.com/rust-lang/rust/issues/28237
* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`
r? petrochenkov
|
|
Detect `=` -> `:` typo in let bindings
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
Fix #43703.
|
|
|
|
Add a nicer error message for missing in for loop, fixes #40782.
As suggested by @estebank in issue #40782, this works in the same way as #42578: if the in keyword is missing, we continue parsing the expression and if this works correctly an adapted error message is produced. Otherwise we return the old error.
A specific test case has also been added.
This is my first PR on rust-lang/rust so any feedback is very welcome.
|
|
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
|
|
This moves the well formedness checks to the AST validation pass. Tests
were adjusted.
The auto keyword should be back-compat now.
|
|
Now we can do the well formedness checks in the parser, yay!
|
|
Adds an `IsAuto` field to `ItemTrait` which flags if the trait was
declared as an `auto trait`.
Auto traits cannot have generics nor super traits.
|
|
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement RFC 1861: Extern types
A few notes :
- Type parameters are not supported. This was an unresolved question from the RFC. It is not clear how useful this feature is, and how variance should be treated. This can be added in a future PR.
- `size_of_val` / `align_of_val` can be called with extern types, and respectively return 0 and 1. This differs from the RFC, which specified that they should panic, but after discussion with @eddyb on IRC this seems like a better solution.
If/when a `DynSized` trait is added, this will be disallowed statically.
- Auto traits are not implemented by default, since the contents of extern types is unknown. This means extern types are `!Sync`, `!Send` and `!Freeze`. This seems like the correct behaviour to me.
Manual `unsafe impl Sync for Foo` is still possible.
- This PR allows extern type to be used as the tail of a struct, as described by the RFC :
```rust
extern {
type OpaqueTail;
}
#[repr(C)]
struct FfiStruct {
data: u8,
more_data: u32,
tail: OpaqueTail,
}
```
However this is undesirable, as the alignment of `tail` is unknown (the current PR assumes an alignment of 1). Unfortunately we can't prevent it in the general case as the tail could be a type parameter :
```rust
#[repr(C)]
struct FfiStruct<T: ?Sized> {
data: u8,
more_data: u32,
tail: T,
}
```
Adding a `DynSized` trait would solve this as well, by requiring tail fields to be bound by it.
- Despite being unsized, pointers to extern types are thin and can be casted from/to integers. However it is not possible to write a `null<T>() -> *const T` function which works with extern types, as I've explained here : https://github.com/rust-lang/rust/issues/43467#issuecomment-321678621
- Trait objects cannot be built from extern types. I intend to support it eventually, although how this interacts with `DynSized`/`size_of_val` is still unclear.
- The definition of `c_void` is unmodified
|
|
Improve diagnostics when list of tokens has incorrect separators
Make `parse_seq_to_before_tokens` more resilient to error conditions. Where possible it is better if it can consume up to the final bracket before returning. This change improves the diagnostics in a couple of situations:
```
struct S(pub () ()); // omitted separator
use std::{foo. bar}; // used a similar but wrong separator
```
Fixes #44339
r? @petrochenkov
|
|
|
|
|
|
r=nikomatsakis
`crate` shorthand visibility modifier
cc #45388.
r? @nikomatsakis
|
|
With regrets, this breaks rustfmt and rls.
This is in the matter of #45388.
|
|
|
|
support generics in each variant of TraitItem and ImplItem
|
|
While an inner attribute here is in fact erroneous, that error ("inner
attribute is not permitted in this context") successfully gets set earlier;
this further admonition is nonsensical.
Resolves #45296.
|
