closes#20953closes#21361
---
In the future, we will likely derive these `impl`s via syntax extensions or using compiler magic (see #20617). For the time being we can use these manual `impl`s.
r? @aturon
cc @burntsushi @Kroisse
There are two limitations to the macro that this addresses:
1. the expected type is not propagated, coercions don't trigger
2. references inside element expressions don't outlive the `Vec`
Both of these limitations are caused by the block in the
macro expansion, previously needed to trigger a coercion
from `Box<[T; N]>` to `Box<[T]>`, now possible with UFCS.
This does the bare minimum to make registration of error codes work again. After this patch, every call to `span_err!` with an error code gets that error code validated against a list in that crate and a new tidy script `errorck.py` validates that no error codes are duplicated globally.
There are further improvements to be made yet, detailed in #19624.
r? @nikomatsakis
The script is intended as a tool for doing every sort of verifications amenable to Rustdoc's HTML output. For example, link checkers would go to this script. It already parses HTML into a document tree form (with a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated to use `htmldocck.py` and got their `verify.sh` removed. In the future they may go to a dedicated directory with htmldocck running by default. The detailed explanation of test scripts is provided as a docstring of htmldocck.
cc #19723
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
This commit aims to stabilize the `TypeId` abstraction by moving it out of the
`intrinsics` module into the `any` module of the standard library. Specifically,
* `TypeId` is now defined at `std::any::TypeId`
* `TypeId::hash` has been removed in favor of an implementation of `Hash`.
This commit also performs a final pass over the `any` module, confirming the
following:
* `Any::get_type_id` remains unstable as *usage* of the `Any` trait will likely
never require this, and the `Any` trait does not need to be implemented for
any other types. As a result, this implementation detail can remain unstable
until associated statics are implemented.
* `Any::downcast_ref` is now stable
* `Any::downcast_mut` is now stable
* `BoxAny` remains unstable. While a direct impl on `Box<Any>` is allowed today
it does not allow downcasting of trait objects like `Box<Any + Send>` (those
returned from `Thread::join`). This is covered by #18737.
* `BoxAny::downcast` is now stable.
Closes#21033. The new strategy for parsing a field pattern is to look 1 token ahead and if it's a colon, parse as "fieldname: pat", otherwise parse the shorthand form "(box) (ref) (mut) fieldname)". The previous strategy was to parse "(ref) (mut) fieldname" then if we encounter a colon, throw an error if either "ref" or "mut" were encountered.
This commit modifies resolve to prevent conflicts with typedef names in the same
method that conflits are prevented with enum names. This is a breaking change
due to the differing semantics in resolve, and any errors generated on behalf of
this change require that a conflicting typedef, module, or structure to be
renamed so they do not conflict.
[breaking-change]
Closes#6936
LLVM gets overwhelmed when presented with a zeroinitializer for a large
type. In unoptimised builds, it generates a long sequence of stores to
memory. In optmised builds, it manages to generate a standard memset of
zero values, but takes a long time doing so.
Call out to the `llvm.memset` function to zero out the memory instead.
Fixes#21264
This commit aims to stabilize the `TypeId` abstraction by moving it out of the
`intrinsics` module into the `any` module of the standard library. Specifically,
* `TypeId` is now defined at `std::any::TypeId`
* `TypeId::hash` has been removed in favor of an implementation of `Hash`.
This commit also performs a final pass over the `any` module, confirming the
following:
* `Any::get_type_id` remains unstable as *usage* of the `Any` trait will likely
never require this, and the `Any` trait does not need to be implemented for
any other types. As a result, this implementation detail can remain unstable
until associated statics are implemented.
* `Any::downcast_ref` is now stable
* `Any::downcast_mut` is now stable
* `BoxAny` remains unstable. While a direct impl on `Box<Any>` is allowed today
it does not allow downcasting of trait objects like `Box<Any + Send>` (those
returned from `Thread::join`). This is covered by #18737.
* `BoxAny::downcast` is now stable.
This commit modifies resolve to prevent conflicts with typedef names in the same
method that conflits are prevented with enum names. This is a breaking change
due to the differing semantics in resolve, and any errors generated on behalf of
this change require that a conflicting typedef, module, or structure to be
renamed so they do not conflict.
[breaking-change]
Closes#6936
* add `Token::AndAnd` (double borrow)
* add `Token::DotDot` (range notation)
* remove `Token::Pound` and `Token::At`
This fixes a syntax error when parsing `fn f() -> RangeTo<i32> { return ..1; }`.
Also, remove `fn_expr_lookahead`.
It's from the `fn~` days and seems to no longer be necessary.
There are two limitations to the macro that this addresses:
1. the expected type is not propagated, coercions don't trigger
2. references inside element expressions don't outlive the `Vec`
Both of these limitations are caused by the block in the
macro expansion, previously needed to trigger a coercion
from `Box<[T; N]>` to `Box<[T]>`, now possible with UFCS.
The script is intended as a tool for doing every sort of verifications
amenable to Rustdoc's HTML output. For example, link checkers would go
to this script. It already parses HTML into a document tree form (with
a slight caveat), so future tests can make use of it.
As an example, relevant `rustdoc-*` run-make tests have been updated
to use `htmldocck.py` and got their `verify.sh` removed. In the future
they may go to a dedicated directory with htmldocck running by default.
The detailed explanation of test scripts is provided as a docstring of
htmldocck.
cc #19723
This stops the compiler ICEing on the use of SIMD types in FFI signatures. It emits correct code for LLVM intrinsics, but I am quite unsure about the ABI handling in general so I've added a new feature gate `simd_ffi` to try to ensure people don't use it without realising there's a non-trivial risk of codegen brokenness.
Closes#20043.
Loading methods from external crates was erroneously using the type's privacy
for each method instead of each method's privacy. This commit fixes that.
Closes#21202
This commit also moves privacy to its own crate because I thought that was where the bug was. Turns out it wasn't, but it helped me iterate at least!
I don't know if this handling of SIMD types is correct for the C ABI on
all platforms, so lets add an even finer feature gate than just the
`simd` one.
The `simd` one can be used with (relatively) little risk of complete
nonsense, the reason for it is that it is likely that things will
change. Using the types in FFI with an incorrect ABI will at best give
absolute nonsense results, but possibly cause serious breakage too, so
this is a step up in badness, hence a new feature gate.
This just compiles a test using SIMD in FFI (mostly importing LLVM
intrinsics) for almost all rustc's supported platforms, but not linking
it or running it, so there's absolutely no guarantee that this is correct.
