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.
- 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
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
Now that `std::cell::Ref::filter_map` and `RefMut::filter_map` are deprecated, using them gives a warning like:
```
script/dom/element.rs:754:9: 754:24 warning: use of deprecated item: can be built on Ref::map, #[warn(deprecated)] on by default
```
But it’s not at all obvious *how* the functionality can be built on `Ref::map`. This PR adds to the warning message a crates.io URL for a crate that does.
- make sure we copy the third party objects (crt*.o) to the target stage directory.
- apply the x86_64-musl logic also to the i686-musl target.
---
r? @alexcrichton
Squashed 10 commits:
1) 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.
2) Update previous commit to comply with rust formatting standards.
Removed tab characters, remove trailing whitespaces.
3) Move emscripten changes into their own file under libstd/os/emscripten
Put libstd/os/linux/fs back to the way it was.
4) Cannot use stat.st_ctim on emscripten to get created time.
5) Remove compile-time conditionals for target_env = musl, it looks like musl builds compile fine already.
6) Undone some formatting changes that are no longer needed,
Removed some more target_env="musl" compilation checks that I missed from my previous commit.
7) upgrade to liblibc e19309c, it fixes the differences in the musl stat and stat64 definitions.
8) Undo the compile-time checks to check for emscripten (or musl targets) in the FileAttr struct.
No longer needed after updating liblibc to e19309c.
9) Change the MetadataExt implementation of emscripten fs.rs module to match the changes in new liblibc.
10) remove a stray return statement, should have been removed in the previous commit.
This adds support for fused multiply-add and multiply-subtract vector intrinsics for 128 and 256-bit vectors of `f32` and `f64`. These correspond to the intrinsics [listed here](https://software.intel.com/en-us/node/523929) except for the `_ss` and `_sd` variants. The intrinsics added are:
* `fmadd`
* `fmaddsub`
* `fmsub`
* `fmsubadd`
* `fnmadd`
* `fnmsub`
The “fma” target feature must be enabled by passing `-C target-feature=+fma` to rustc when using these, otherwise LLVM will complain.
I verified locally that the `x86_mm256_fmadd_ps` and `x86_mm256_fmsub_ps` work.
Fix panic on string slicing error to truncate the string
The string may be arbitrarily long, but we want to limit the panic
message to a reasonable length. Truncate the string if it is too long
(simply to char boundary).
Also add details to the start <= end message. I think it's ok to flesh
out the code here, since it's in a cold function.
Fixes#32063
Adding -Wno-error is more reliable and simple than trying to modify existing
flags. We've been using this in Debian already for the past few releases.
Making this change also encourages future maintainers towards "best practises".
Also take the opportunity to use the same method at all places in the file.
Do not trigger unused_assignments for overloaded AssignOps
If `v` were a type with some kind of indirection, so that `v += 1` would
have an effect even if `v` were not used anymore, the unused_assignments lint
would mark a false positive.
This exempts overloaded (non-primitive) assign ops from being treated as
assignments (they are method calls).
The previous compile-fail tests that ensure x += 1 can trigger for
primitive types continue to pass. Added a representative test for the
"view" indirection.
Fixes#31895
These were intended to land in stable 1.8 but were just waiting for the
implementation PR, so now they're landing. Specifically this PR stabilizes:
* `AsciiExt::into_ascii_uppercase`
* `AsciiExt::into_ascii_lowercase`
* `AsciiExt for Vec<u8>`
* `AsciiExt for String`
This is mostly cleanup of individual code bits and code reuse for `clean::Attribute` handling.
The only change in behaviour should be that emitted sources are now being recorded and queried when trying to create src-links to local source-files.
r? @alexcrichton
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges.
This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals.
- For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from https://github.com/rust-lang/rfcs/pull/1192#issuecomment-137864421. It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion.
- I also kind of like @glaebhoerl's [idea](https://github.com/rust-lang/rfcs/pull/1254#issuecomment-147815299), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate.
- There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging.
cc @Gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq)
cc #27777#30877rust-lang/rust#1192rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
This PR allows using methods from traits that are visible but are defined in an inaccessible module (fixes#18241). For example,
```rust
mod foo {
pub use foo::bar::Tr;
mod bar { // This module is inaccessible from `g`
pub trait Tr { fn f(&self) {} }
}
}
fn g<T: foo::Tr>(t: T) {
t.f(); // Currently, this is a privacy error even though `foo::Tr` is visible
}
```
After this PR, it will continue to be a privacy error to use a method from a trait that is not visible. This can happen when a public trait inherits from a private trait (in violation of the `public_in_private` lint) -- see @petrochenkov's example in #28504.
r? @nikomatsakis
