The very first code fragment off every struct and trait documentation page generates wrong playground code. This pull request adjusts ```playpen.js``` to only create a link for real examples.
Documentation:
```rust
pub struct String {
// some fields omitted
}
```
Playground:
```rust
Struct std::String
[−]
[src]
```
r? @steveklabnik
Avoids some code duplication and relies less on deprecated properties on `KeyboardEvent`. The code is still looking quite bad, but that’s primarily because interop in this area is a disaster zone.
Sharpens the help dialogues edges by removing border-padding, which
matches better with the rest of the document.
Also increases somewhat the rounded edges of the key symbols to
make it clear they are symbols.
Also introduces closing apostrophes and ellipsis for search field
placeholder.
I noticed in docs, specifically http://doc.rust-lang.org/std/primitive.u8.html#method.is_power_of_two, that it was like this, and it was apparently in multiple places too.
Didn't change any occurrences through the cross-depo things. There's a lot in /src/llvm/ for instance, but I'm not confident on how to go about sending fixes for those, so this is just what's in the base rust depo.
r? @steveklabnik
Previously on Windows a directory junction would return false from `is_dir`,
causing various odd behavior, specifically calls to `create_dir_all` might fail
when they would otherwise continue to succeed.
Closes#26716
This makes `Debug` for `File` show the file path and access mode of the file on OS X, just like on Linux.
I'd be happy about any feedback how to make this code better. In particular, I'm not sure how to handle the buffer passed to `fnctl`. This way works, but it feels a bit cumbersome. `fcntl` unfortunately doesn't return the length of the path.
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
Previously on Windows a directory junction would return false from `is_dir`,
causing various odd behavior, specifically calls to `create_dir_all` might fail
when they would otherwise continue to succeed.
Closes#26716
This allows CString and CStr to be used with the Cow type,
which is extremely useful when interfacing with C libraries
that make extensive use of C-style strings.
There are a number of problems with MSVC landing pads today:
* They only work about 80% of the time with optimizations enabled. For example when running the run-pass test suite a failing test will cause `compiletest` to segfault (b/c of a thread panic). There are also a large number of run-fail tests which will simply crash.
* Enabling landing pads caused the regression seen in #26915.
Overall it looks like LLVM's support for MSVC landing pads isn't as robust as we'd like for now, so let's take a little more time before we turn them on by default.
Closes#26915
