This is done in order to deprecate AsciiExt eventually. Note that
this commit contains a bunch of `cfg(stage0)` statements. This is
due to a new compiler feature this commit depends on: the
`slice_u8` lang item. Once this lang item is available in the
stage0 compiler, all those cfg flags (and more) can be removed.
This is done in order to deprecate AsciiExt eventually. Note that
this commit contains a bunch of `cfg(stage0)` statements. This is
due to a new compiler feature I am using: the `slice_u8` lang item.
Once this lang item is available in the stage0 compiler, all those
cfg flags (and more) can be removed.
The doc comments were incorrect before: since the inherent ascii methods
shadow the `AsciiExt` methods, the examples didn't use the `AsciiExt` at
all. Since the trait will be deprecated soon anyway, the easiest solution
was to remove the examples and already mention that the methods will be
deprecated in the near future.
Since the methods on u8 directly will shadow the AsciiExt methods,
we cannot change the signature without breaking everything. It
would have been nice to take `u8` as argument instead of `&u8`, but
we cannot break stuff! So this commit reverts it to the original
`&u8` version.
Those methods will shadow the methods of `AsciiExt`, so if we don't
make them insta-stable, everyone will hitting stability errors. It
is fine adding those as stable, because they are just being moved
around [according to sfackler][1].
OPEN QUESTION: this commit also stabilizes the `AsciiExt` methods
that were previously feature gated by the `ascii_ctype` feature.
Maybe we don't want to stablilize those yet.
[1]: https://github.com/rust-lang/rust/pull/44042#issuecomment-329939279
This is the first step in order to deprecate AsciiExt. Since
this is a WIP commit, there is still some code duplication (notably
the static arrays) that will be removed later.
[Syntax] Implement auto trait syntax
Implements `auto trait Send {}` as a substitute for `trait Send {} impl Send for .. {}`.
See the [internals thread](https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086) for motivation. Part of #13231.
The first commit is just a rename moving from "default trait" to "auto trait". The rest is parser->AST->HIR work and making it the same as the current syntax for everything below HIR. It's under the `optin_builtin_traits` feature gate.
When can we remove the old syntax? Do we need to wait for a new `stage0`? We also need to formally decide for the new form (even if the keyword is not settled yet).
Observations:
- If you `auto trait Auto {}` and then `impl Auto for .. {}` that's accepted even if it's redundant.
- The new syntax is simpler internally which will allow for a net removal of code, for example well-formedness checks are effectively moved to the parser.
- Rustfmt and clippy are broken, need to fix those.
- Rustdoc just ignores it for now.
ping @petrochenkov @nikomatsakis
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`.
`unreachable-pub` lint (as authorized by RFC 2126)
To whom it may concern:
RFC 2126 commissions the creation of a lint for `pub` items that are not visible from crate root (#45521). We understand (but seek confirmation from more knowledgable compiler elders) that this can be implemented by linting HIR items that are _not_ ~~`cx.access_levels.is_exported`~~ `cx.access_levels.is_reachable` but have a `vis` (-ibility) field of `hir::Visibility::Public`.
The lint, tentatively called ~~`unexported-pub`~~ `unreachable-pub` (with the understanding that much could be written on the merits of various names, as it is said of the colors of bicycle-sheds), suggests `crate` as a replacement for `pub` if the `crate_visibility_modifier` feature is enabled (see #45388), and `pub(crate)` otherwise. We also use help messaging to suggest the other potential fix of exporting the item; feedback is desired as to whether this may be confusing or could be worded better.
As a preview of what respecting the proposed lint would look like (and to generate confirmatory evidence that this implementation doesn't issue false positives), ~~we take its suggestions for `libcore`~~ (save one, which is deferred to another pull request because it brings up an unrelated technical matter). I remain your obedient servant.
r? @petrochenkov
ci: Fix broken link in `build-powerpc64le-toolchain.sh`
r? @rust-lang/infra
This is just an emergency fix to keep bors running for another week. I think the numbers will be broken soon. Can we verify if this statement is still true later?
> First, download the CentOS7 glibc.ppc64le and relevant header files.
> (upstream ppc64le support wasn't added until 2.19, which el7 backported.)
