This multiline string literal was missing a backslash, leaving an awkward
newline and 35 spaces in the middle of the message.
But while we're here, the existing message seems kind of long in comparison to
similar notes: to cut it down, we excise the mentions of doc comments, which
seems sensible because we know that this erroneous attribute is not a doc
comment (notice the `is_sugared_doc: false` at the end of the function; if it
had been a doc comment, that error would get set in the `token::DocComment`
match branch of `parse_outer_attributes`).
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
Move Generics from MethodSig to TraitItem and ImplItem
As part of `rust-impl-period/WG-compiler-traits`, we want to "lift" `Generics` from `MethodSig` into `TraitItem` and `ImplItem`. This is in preparation for adding associated type generics. (https://github.com/rust-lang/rust/issues/44265#issuecomment-331172238)
Currently this change is only made in the AST. In the future, it may also impact the HIR. (Still discussing)
To understand this PR, it's probably best to start from the changes to `ast.rs` and then work your way to the other files to understand the far reaching effects of this change.
r? @nikomatsakis
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.
Better error message for comma after base struct
#41834
This adds a better error for commas after the base struct:
```
let foo = Foo {
one: 111,
..Foo::default(), // This comma is a syntax error
};
```
The current error is a generic `expected one of ...` which isn't beginner-friendly. My error looks like this:
```
error: cannot use a comma after the base struct
--> tmp/example.rs:26:9
|
26 | ..Foo::default(),
| ^^^^^^^^^^^^^^^^- help: remove this comma
|
= note: the base struct expansion must always be the last field
```
I even added a note for people who don't know why this isn't allowed.
fix ItemKind::DefaultImpl doc comment
Upgrade comment to doc comment.
...Is this actually used? If so, why does the `Impl` variant right below have a `Defaultness`?
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays.
remove FIXME(#19649) now that stability markers render.
remove FIXME(#13642) now the benchmarks were moved.
remove FIXME(#6220) now that floating points can be formatted.
remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>`
remove reference to irelevent issues in FIXME(#1697, #2178...)
update FIXME(#5516) to point to getopts issue 7
update FIXME(#7771) to point to RFC 628
update FIXME(#19839) to point to issue 26925
First step toward implementing impl Trait in argument position
First step implementing #44721.
Add a flag to hir and ty TypeParameterDef and raise an error when using
explicit type parameters when calling a function using impl Trait in
argument position.
I don't know if there is a procedure to add an error code so I just took an available code. Is that ok ?
r? @nikomatsakis
Initial support for `..=` syntax
#28237
This PR adds `..=` as a synonym for `...` in patterns and expressions.
Since `...` in expressions was never stable, we now issue a warning.
cc @durka
r? @aturon
Add a flag to hir and ty TypeParameterDef and raise an error when using
explicit type parameters when calling a function using impl Trait in
argument position.
add comparison operators to must-use lint (under `fn_must_use` feature)
Although RFC 1940 is about annotating functions with `#[must_use]`, a
key part of the motivation was linting unused equality operators.
(See
https://github.com/rust-lang/rfcs/pull/1812#issuecomment-265695898—it
seems to have not been clear to discussants at the time that marking the
comparison methods as `must_use` would not give us the lints on
comparison operators, at least in (what the present author understood
as) the most straightforward implementation, as landed in #43728
(3645b062).)
To rectify the situation, we here lint unused comparison operators as
part of the unused-must-use lint (feature gated by the `fn_must_use`
feature flag, which now arguably becomes a slight (tolerable in the
opinion of the present author) misnomer).
This is in the matter of #43302.
cc @crumblingstatue
Zack M. Davis
