This defines `_mm256_broadcast_ps` and `_mm256_broadcast_pd`. The `_ss`
and `_sd` variants are not supported by LLVM. In Clang these intrinsics
are implemented as inline functions in C++.
Intel reference: https://software.intel.com/en-us/node/514144.
Note: the argument type should really be "0hPc" (a pointer to a vector
of half the width), but internally the LLVM intrinsic takes a pointer to
a signed integer, and for any other type LLVM will complain. This means
that a transmute is required to call these intrinsics.
The AVX2 broadcast intrinsics `_mm256_broadcastss_ps` and
`_mm256_broadcastsd_pd` are not available as LLVM intrinsics. In Clang
they are implemented using the shufflevector builtin.
As part of the ongoing effort to document all methods with examples,
this commit adds the missing examples for the `BinaryHeap` collection
type.
This is part of issue #29348.
As part of the ongoing effort to document all methods with examples,
this commit adds the missing examples for the `BTreeSet` collection
type.
This is part of issue #29348.
As part of the ongoing effort to document all methods with examples,
this commit adds the missing examples for the `BTreeMap` collection
type.
This is part of issue #29348.
Right now whenever rustdoc inlines a struct or enum from another crate it ends
up inlining *all* `impl` items found in the other crate at the same time. The
rationale for this was to discover all trait impls which are otherwise not
probed for. This unfortunately picks up a lot of impls of public traits for
private types, causing lots of broken links.
This commit instead hoards all of those inlined impls into a temporary storage
location which is then selectively drawn from whenever we inline a new type.
This should ensure that we still inline all relevant impls while avoiding all
private ones.
This is actually a reexported implementation detail in the `rt::v1` module but
rustdoc doesn't like reexporting items from `doc(hidden)` modules. Do what we'd
end up doing anyway from an API perspective and make a public-facing `enum` that
can be retranslated under the hood if necessary.
A few categories:
* Links into compiler docs were just all removed as we're not generating
compiler docs.
* Move up one more level to forcibly go to std docs to fix inlined documentation
across the facade crates.
Add a script to get run which verifies that `href` links in documents are
correct. We're always getting a steady stream of "fix a broken link" PRs and
issue reports, and we should probably just nip them all in the bud.
Run `cargo doc` to generate all documentation for the standard library, and also
add a target which generates documentation for the compiler as well (but don't
enable it by default).
Clarify documentation for string slicing (Index impls)
Clarify documentation for string slicing (Index impls)
- Mention the sugared syntax for the implementations, since it's not
apparent from the docs that `Index<Range<usize>>` corresponds to
`&self[a..b]`.
- Be specific in that start <= end and end <= len
This is just one fix in response to #32057
Clarify the semantics of enum discriminants
cf. https://doc.rust-lang.org/error-index.html#E0082
> The default type for enum discriminants is isize, but it can be adjusted by adding the repr attribute to the enum declaration.
It would be great if anyone could check my English.
mk: Distribute fewer TARGET_CRATES
Right now everything in TARGET_CRATES is built by default for all non-fulldeps
tests and is distributed by default for all target standard library packages.
Currenly this includes a number of unstable crates which are rarely used such as
`graphviz` and `rbml`>
This commit trims down the set of `TARGET_CRATES`, moves a number of tests to
`*-fulldeps` as a result, and trims down the dependencies of libtest so we can
distribute fewer crates in the `rust-std` packages.
Add error file for E0152
It completes #31818.
However it is not complete yet:
* test will need to be updated
* the file name displayed is a bit too unclear.
I'm not sure yet what's the "correct" file name to display. If anyone has an idea on this, it'd be very appreciated.
r? @brson
implement the `?` operator
The `?` postfix operator is sugar equivalent to the try! macro, but is more amenable to chaining:
`File::open("foo")?.metadata()?.is_dir()`.
`?` is accepted on any *expression* that can return a `Result`, e.g. `x()?`, `y!()?`, `{z}?`,
`(w)?`, etc. And binds more tightly than unary operators, e.g. `!x?` is parsed as `!(x?)`.
cc #31436
---
cc @aturon @eddyb
Fix building libstd on emscripten targets.
The main cause of the problem is that libstd/os/mod.rs treats emscripten targets as an alias of linux targets, whereas liblibc treats emscripten targets as musl-compliant, so it gets a slightly different struct stat64 defined.
This commit adds conditional compilation checks to use the correct timestamp format on fs metadata functions in the case of compiling to emscripten targets.
This commit also depends needs f1575cff2d applied in order to successfully build libstd with emscripten target.
Right now everything in TARGET_CRATES is built by default for all non-fulldeps
tests and is distributed by default for all target standard library packages.
Currenly this includes a number of unstable crates which are rarely used such as
`graphviz` and `rbml`>
This commit trims down the set of `TARGET_CRATES`, moves a number of tests to
`*-fulldeps` as a result, and trims down the dependencies of libtest so we can
distribute fewer crates in the `rust-std` packages.
