This function is very hot, doesn't get inlined because it's recursive,
and the function calls are significant.
This commit splits it into inlined and uninlined variants, and uses the
inlined variant for the hot call site. This wins several percent on a
few benchmarks.
Update cargo
11 commits in fe0e5a48b75da2b405c8ce1ba2674e174ae11d5d..9655d70af8a6dddac238e3afa2fec75088c9226f
2019-09-04 00:51:27 +0000 to 2019-09-10 18:16:11 +0000
- Home docs: fix broken links, misspellings, style fixes, clarifications. (rust-lang/cargo#7348)
- add readme key to cargos manifest. (rust-lang/cargo#7347)
- Explicitly ignore some results (rust-lang/cargo#7340)
- Don't resolve std's optional dependencies (rust-lang/cargo#7337)
- Add `alloc` and `proc_macro` to libstd crates (rust-lang/cargo#7336)
- doc: capitalization change for consistency. (rust-lang/cargo#7334)
- Fix test for changes in plugin API. (rust-lang/cargo#7335)
- Fix some man pages where the files weren't rebuilt. (rust-lang/cargo#7332)
- guide: add section about the cargo home (rust-lang/cargo#7314)
- `map_dependencies` is doing a deep clone, so lets make it cheaper (rust-lang/cargo#7326)
- don't need to copy this string (rust-lang/cargo#7324)
- Create ErrorReportingCtx and ErrorConstraintInfo, vasting reducing the
number of arguments passed around everywhere in the error reporting code
- Create RegionErrorNamingCtx, making a given lifetime have consistent
numbering thoughout all error messages for that MIR def.
- Make the error reporting code return the DiagnosticBuilder rather than
directly buffer the Diagnostic. This makes it easier to modify the
diagnostic later, e.g. to add suggestions.
rustdoc: change doctests locating rustc binary
We previously used the "naive" approach of replacing the `current_exe()`'s file name with rustc, but now load from the sysroot by default (`$sysroot/bin/rustc`). The functionality of locating the sysroot overlaps/is the same as the functionality used by codegen backend loading; this ensures that any failure cases we've introduced are not exceeding those, and that improvements to finding the sysroot for loading codegen backends likewise enhance rustdoc.
The second commit adds an unstable `--test-builder` flag to rustdoc, and is largely separate (I can split into separate PR, but it's a simple and related change). This is largely intended for "advanced" users at this point (I'm not sure if we'll ever stabilize it); it permits use of a different rustc binary for rustdoc compilation of doctests than the rustdoc binary used when loading. Note, that this may not be what you want as the parsers and such differ (and rustdoc uses its own libsyntax, etc.). However, I've been told that running doctests in miri may be assisted by this change, so I've implemented it; I'll file a tracking issue for it if there's interest in it (and we land this PR).
Avoid more `Symbol`-to-string operations
These commits avoid various `Symbol`-to-string conversions, by doing more operations directly on `Symbol`s. This requires adding a few more static `Symbol`s to the binary.
r? @petrochenkov
Add i686-unknown-uefi target
This adds a new rustc target-configuration called 'i686-unknown_uefi'.
This is similar to existing x86_64-unknown_uefi target.
The i686-unknown-uefi target can be used to build Intel Architecture
32bit UEFI application. The ABI defined in UEFI environment (aka IA32)
is similar to cdecl.
We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid
the intrinsics generated by LLVM. The detail of root-cause and solution
analysis is added as comment in the code.
For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between
MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC.
For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as
MSVC and GNU. According to LLVM code, the only differences between MSVC
and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI.
As such, using i686-unknown-uefi-gnu is the simplest way to pass the build.
Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins
is out of scope. But it may be considered later.
The scope of this patch is limited to support target-configuration.
No standard library support is added in this patch. Such work can be
done in future enhancement.
Cc: Josh Triplett <josh.triplett@intel.com>
Reviewed-by: Josh Triplett <josh.triplett@intel.com>
It's a large type -- 176 bytes on 64-bit. And it's passed around and
returned from a lot of functions, including within PResult.
This commit boxes it, which reduces memory traffic. In particular,
`PResult` shrinks to 16 bytes in the best case; this reduces instruction
counts by up to 2% on various workloads.
check_match: refactor + improve non-exhaustive diagnostics for default binding modes
Refactor `check_match` a bit with more code-reuse and improve the diagnostics for a non-exhaustive pattern match by peeling off any references from the scrutinee type so that the "defined here" label is added in more cases. For example:
```rust
error[E0004]: non-exhaustive patterns: `&mut &B` not covered
--> foo.rs:4:11
|
1 | enum E { A, B }
| ---------------
| | |
| | not covered
| `E` defined here
...
4 | match x {
| ^ pattern `&mut &B` not covered
|
= help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
```
Moreover, wrt. "defined here", we give irrefutable pattern matching (i.e. in `let`, `for`, and `fn` parameters) a more consistent treatment in line with `match`.
r? @estebank
std: Add a `backtrace` module
This commit adds a `backtrace` module to the standard library, as
designed in [RFC 2504]. The `Backtrace` type is intentionally very
conservative, effectively only allowing capturing it and printing it.
Additionally this commit also adds a `backtrace` method to the `Error`
trait which defaults to returning `None`, as specified in [RFC 2504].
More information about the design here can be found in [RFC 2504] and in
the [tracking issue].
Implementation-wise this is all based on the `backtrace` crate and very
closely mirrors the `backtrace::Backtrace` type on crates.io. Otherwise
it's pretty standard in how it handles everything internally.
[RFC 2504]: https://github.com/rust-lang/rfcs/blob/master/text/2504-fix-error.md
[tracking issue]: https://github.com/rust-lang/rust/issues/53487
cc #53487
Rollup of 6 pull requests
Successful merges:
- #64060 (Improve hygiene of `alloc::format!`)
- #64072 (Replace file_stem by file_name in rustdoc markdown)
- #64129 (vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn)
- #64188 (rustc: Allow the cdylib crate type with wasm32-wasi)
- #64326 (Fixed documentation within c_str::from_ptr)
- #64349 (documentation for AtomicPtr CAS operations)
Failed merges:
r? @ghost
documentation for AtomicPtr CAS operations
The examples in the documentation for AtomicPtr CAS operations only show code that does *not* perform the CAS operation. I suggest to change them so that they actually do exchange the AtomicPtr's value.
rustc: Allow the cdylib crate type with wasm32-wasi
The wasm32-wasi target respects configuration around `crt-static` in
general, but is defaulted to being static. This interacted badly with
code which validated the `cdylib` crate type for `wasm32-wasi`,
erroneously saying that the `cdylib` crate type wasn't supported on
`wasm32-wasi` by default. This commit sets the appropriate flag in
`wasm32_wasi`'s target specification to indicate that the `cdylib` crate
type is supported regardless of `crt-static`
Closes#64187
vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn
vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn
r? @alexcrichton
cc @n-salim
Replace file_stem by file_name in rustdoc markdown
Before this PR, a file name like `some.file.md` will be output to a file named `some.html` with is not correct because the expected output file must be `some.file.html`
