Did this alphabetically, so I didn't see [how `std` was doing things](https://dxr.mozilla.org/rust/source/src/libstd/lib.rs#215) till I was nearly finished. If you prefer to add crate-level-whitelists like std instead of test-level, I can rebase with that strategy.
A number of these commits can probably be dropped as the crates don't have much to test, and are deprecated. Let me know which if any to drop! (can also squash after review if desired)
r? @steveklabnik
This commit adds issue numbers to the vast majority of active feature
gates. The few that are left without issues are rustc/runtime-internal
features that are essentially private APIs.
Closes#28244
r? @huonw
* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c
This commit adds issue numbers to the vast majority of active feature
gates. The few that are left without issues are rustc/runtime-internal
features that are essentially private APIs.
Closes#28244
If you try to put something that's bigger than a char into a char
literal, you get an error:
fn main() {
let c = 'ஶ்ரீ';
}
error: unterminated character constant:
This is a very compiler-centric message. Yes, it's technically
'unterminated', but that's not what you, the user did wrong.
Instead, this commit changes it to
error: character literal that's larger than a char:
As this actually tells you what went wrong.
Fixes#28851
If you try to put something that's bigger than a char into a char
literal, you get an error:
fn main() {
let c = 'ஶ்ரீ';
}
error: unterminated character constant:
This is a very compiler-centric message. Yes, it's technically
'unterminated', but that's not what you, the user did wrong.
Instead, this commit changes it to
error: character literal may only contain one codepoint
As this actually tells you what went wrong.
Fixes#28851
The public set is expanded with trait items, impls and their items, foreign items, exported macros, variant fields, i.e. all the missing parts. Now it's a subset of the exported set.
This is needed for https://github.com/rust-lang/rust/pull/29083 because stability annotation pass uses the public set and all things listed above need to be annotated.
Rustdoc can now be migrated to the public set as well, I guess.
Exported set is now slightly more correct with regard to exported items in blocks - 1) blocks in foreign items are considered and 2) publicity is not inherited from the block's parent - if a function is public it doesn't mean structures defined in its body are public.
r? @alexcrichton or maybe someone else
This helps for the case where a match, such as below:
```rust
let foo = match foo {
Some(x) => x,
None => 0
};
```
gets refactored to no longer need the match, but the match keyword has been left accidentally:
```rust
let foo = match foo.unwrap_or(0);
```
This can be hard to spot as the expression grows more complex.
r? @alexcrichton
This commit generalises parsing of associative operators from left-associative
only (with some ugly hacks to support right-associative assignment) to properly
left/right-associative operators.
Parsing still is not general enough to handle non-associative,
non-highest-precedence prefix or non-highest-precedence postfix operators (e.g.
`..` range syntax), though. That should be fixed in the future.
Lastly, this commit adds support for parsing right-associative `<-` (left arrow)
operator with precedence higher than assignment as the operator for placement-in
feature.
This PR switches the implemented ordering from `unsafe const fn` (as was in the original RFC) to `const unsafe fn` (which is what the lang team decided on)
Previously, if you copied a signature from a trait definition such as:
```rust
fn foo<'a>(&'a Bar) -> bool {}
```
and moved it into an `impl`, there would be an error message:
"unexpected token `'a`"
Adding to the error message that a pattern is expected should help
users to find the actual problem with using a lifetime here.
