bors [Sat, 30 Mar 2019 14:12:12 +0000 (14:12 +0000)]
Auto merge of #59561 - Centril:rollup, r=Centril
Rollup of 5 pull requests
Successful merges:
- #59343 (rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`.)
- #59380 (Fix invalid DWARF for enums when using ThinLTO)
- #59463 (skip dyn keyword lint under macros)
- #59539 (Fix infinite recursion)
- #59544 (manifest: only include miri on the nightly channel)
Rollup merge of #59544 - cuviper:miri-nightly, r=Centril
manifest: only include miri on the nightly channel
miri needs to build std with xargo, which doesn't allow stable/beta:
<https://github.com/japaric/xargo/pull/204#issuecomment-374888868>
Therefore, at this time there's no point in making miri available on any
but the nightly channel. If we get a stable way to build `std`, like
[RFC 2663], then we can re-evaluate whether to start including miri,
perhaps still as `miri-preview`.
Rollup merge of #59463 - pnkfelix:issue-56327-skip-dyn-keyword-lint-under-macros, r=matthewjasper
skip dyn keyword lint under macros
This PR is following my own intuition that `rustfix` should never inject bugs into working code (even if that comes at the expense of it failing to fix things that will become bugs).
Rollup merge of #59380 - philipc:thinlto-variant, r=michaelwoerister
Fix invalid DWARF for enums when using ThinLTO
We were setting the same identifier for both the DW_TAG_structure_type
and the DW_TAG_variant_part. This becomes a problem when using ThinLTO
becauses it uses the identifier as a key for a map of types that is used
to delete duplicates based on the ODR, so one of them is deleted as a
duplicate, resulting in invalid DWARF.
The DW_TAG_variant_part isn't a standalone type, so it doesn't need
an identifier. Fix by omitting its identifier.
Rollup merge of #59343 - eddyb:rm-def-symbol-name, r=michaelwoerister
rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`.
The `def_symbol_name` query was an optimization to avoid recomputing the common part of a symbol name, as only the hash needs to be added to it for each symbol.
However, #57967 will add a new mangling scheme, which doesn't readily support this kind of reuse - while it's plausible, it requires a lot more effort, since you'd have to "symbolically evaluate" mangling, and keep it in a form where the backreference positions can be computed correctly in the final step.
So I want to see how much time we're actually saving with this `def_symbol_name` optimization, nowadays.
bors [Sat, 30 Mar 2019 08:32:13 +0000 (08:32 +0000)]
Auto merge of #59550 - Centril:rollup, r=Centril
Rollup of 10 pull requests
Successful merges:
- #59376 (RFC 2008: Enum Variants)
- #59453 (Recover from parse error in tuple syntax)
- #59455 (Account for short-hand field syntax when suggesting borrow)
- #59499 (Fix broken download link in the armhf-gnu image)
- #59512 (implement `AsRawFd` for stdio locks)
- #59525 (Whitelist some rustc attrs)
- #59528 (Improve the dbg! macro docs )
- #59532 (In doc examples, don't ignore read/write results)
- #59534 (rustdoc: collapse blanket impls in the same way as normal impls)
- #59537 (Fix OnceWith docstring.)
Rollup merge of #59534 - laurmaedje:collapse-blanket-impls, r=GuillaumeGomez
rustdoc: collapse blanket impls in the same way as normal impls
If the rustdoc setting _Auto-hide trait implementations documentation_ is activated (on by default), normal trait implementations are collapsed by default.
Blanket impls on the other hand are not collapsed. I'm not sure whether this is intended, but considering that the blanket impls for `From`, `Into`, `TryFrom`, ... are on every type, it would reduce the documentation bloat if these would also be collapsed when the setting is active.
(I'm not really familiar with the codebase and therefore just copied the code for the normal impl collapsing, but I could deduplicate it into a method, of course, too.)
Calling `Read::read` or `Write::write` without checking the returned `usize` value is almost always an error. Example code in the documentation should demonstrate how to use the return value correctly. Otherwise, people might copy the example code thinking that it is okay to "fire and forget" these methods.
Rollup merge of #59528 - DevQps:improve-dbg-macro-docs, r=Centril
Improve the dbg! macro docs
# Description
As stated has been discussed in #58383 the docs do not clearly state why it is useful to have the option to use `dbg!` in release builds as well. This PR should change that.
Rollup merge of #59525 - pnkfelix:whitelist-some-rustc-attrs, r=petrochenkov
Whitelist some rustc attrs
These rustc attrs are used within libcore, and were causing failures when one mixed incremental compilation with bootstrapping (due to a default of `-D warnings` when bootstrapping).
Rollup merge of #59376 - davidtwco:finally-rfc-2008-variants, r=petrochenkov,QuietMisdreavus
RFC 2008: Enum Variants
Part of #44109. See [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rfc-2008/near/132663140) for previous discussion.
bors [Sat, 30 Mar 2019 02:34:13 +0000 (02:34 +0000)]
Auto merge of #59464 - alexcrichton:wasi-pr, r=fitzgen
Add a new wasm32-unknown-wasi target
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
Josh Stone [Sat, 30 Mar 2019 00:59:07 +0000 (17:59 -0700)]
manifest: only include miri on the nightly channel
miri needs to build std with xargo, which doesn't allow stable/beta:
<https://github.com/japaric/xargo/pull/204#issuecomment-374888868>
Therefore, at this time there's no point in making miri available on any
but the nightly channel. If we get a stable way to build `std`, like
[RFC 2663], then we can re-evaluate whether to start including miri,
perhaps still as `miri-preview`.
Alex Crichton [Wed, 13 Feb 2019 18:02:22 +0000 (10:02 -0800)]
Add a new wasm32-unknown-wasi target
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
bors [Fri, 29 Mar 2019 21:46:15 +0000 (21:46 +0000)]
Auto merge of #58846 - bjorn3:misc_cg_ssa_refactor, r=eddyb
Misc refactorings to rustc_codegen_ssa
Unlike #56636 this doesn't split `BuilderMethods` into a lot of traits. That makes this PR twice as small and the split turned out to not be very useful anyway.
Matt Brubeck [Fri, 29 Mar 2019 16:30:08 +0000 (09:30 -0700)]
In doc examples, don't ignore read/write results
Calling `Read::read` or `Write::write` without checking the returned
`usize` value is almost always an error. Example code in the
documentation should demonstrate how to use the return value correctly.
Otherwise, people might copy the example code thinking that it is okay
to "fire and forget" these methods.
Rollup merge of #59454 - topecongiro:rustfmt-1.2.0, r=nrc
Update rustfmt to 1.2.0
This release includes bug fixes and performance improvements from 1.1.0. Also it adds a new rustfmt tool attribute `#[rustfmt::skip::macros]`, which lets you skip formatting macro calls of your choice.
15 commits in 41493ffce5d0e17d54eaf5ec9a995054e2b9aece..27ad493a10364e907ec476e2ad61e8a1614b57e1
2019-03-05 12:32:22 +0100 to 2019-03-26 02:06:15 +0100
- Document wasm_import_module for #[link]. (rust-lang-nursery/reference#554)
- Fix tidy error. (rust-lang-nursery/reference#552)
- Some minor contributing updates. (rust-lang-nursery/reference#551)
- Document `type_length_limit`. (rust-lang-nursery/reference#546)
- Add some terms to the glossary. (rust-lang-nursery/reference#547)
- Document `target_feature` and `cfg_target_feature`. (rust-lang-nursery/reference#545)
- Remove undocumented page (rust-lang-nursery/reference#539)
- Reorg and update attributes (rust-lang-nursery/reference#537)
- Fix some minor link errors. (rust-lang-nursery/reference#538)
- Add linkchecker. (rust-lang-nursery/reference#521)
- Expand docs on Macros By Example. (rust-lang-nursery/reference#511)
- document #[panic_handler] (rust-lang-nursery/reference#362)
- document #[used] (rust-lang-nursery/reference#361)
- Note that UB is program-global (rust-lang-nursery/reference#490)
- Fix copy-paste error in procedural-macros.md (rust-lang-nursery/reference#533)
## book
16 commits in 9cffbeabec3bcec42d09432bfe7705125c848889..b93ec30bbc7b1b5c2f44223249ab359bed2ed5a6
2019-03-02 08:22:41 -0500 to 2019-03-26 16:54:10 -0400
- Unignore example that now compiles
- Fix code snippet (rust-lang/book#1863)
- Fix mdbook link text in readme (rust-lang/book#1881)
- Wrap to 80 cols
- Make sentence more complete (rust-lang/book#1885)
- consistenly use increment and decrement (rust-lang/book#1884)
- Fix link to Reference's conditional-compilation. (rust-lang/book#1878)
- Fix subject/verb agreement
- Remove nostarch snapshot files that have been incorporated and checked
- haha teach the dictionary steve's name
- Add authorship info to the front page
- fix accidental <ol>'s (rust-lang/book#1866)
- Edits to Macros (rust-lang/book#1848)
- Mention `lock` returns `MutexGuard` wrapped in a `LockResult`
- Add an example that illustrates NLL (rust-lang/book#1842)
- change the parameter name from `type` to `kind` (rust-lang/book#1845)
## rust-by-example
33 commits in 2ce92beabb912d417a7314d6da83ac9b50dc2afb..f68ef3d0f4959f6a7d92a08d9994b117f0f4d32d
2018-11-20 10:10:23 -0500 to 2019-03-12 15:32:12 -0300
- Fix some broken links. (rust-lang/rust-by-example#1161)
- Update links in README (rust-lang/rust-by-example#1167)
- Add score/lifetimes/trait.md (rust-lang/rust-by-example#1168)
- Fix rust-lang/rust-by-example#1147 - No more `open_mode` method (rust-lang/rust-by-example#1164)
- Fix for loop description in list print example (rust-lang/rust-by-example#1162)
- Add link to Cargo chapter in the index page (rust-lang/rust-by-example#1159)
- Fix grammar in sentence about integer notation (rust-lang/rust-by-example#1157)
- Do not use deprecated functions from `std::error::Error` trait (rust-lang/rust-by-example#1151)
- Update new_types.md to clarify conversion to base type (rust-lang/rust-by-example#1148)
- Fix compatibility with Rust 2018 (rust-lang/rust-by-example#1150)
- Hello: Fix hint link in `fmt` chapter. (rust-lang/rust-by-example#1146)
- Clarify pub(restricted) example a bit (rust-lang/rust-by-example#1133)
- Add "literal" to list of macro designators (rust-lang/rust-by-example#1153)
- Minor fixes for the macros chapter (rust-lang/rust-by-example#1113)
- Use new book links instead of the old second-edition ones (rust-lang/rust-by-example#1143)
- Recommend implementing Display over ToString (rust-lang/rust-by-example#1145)
- Remove unused import and format with `rustfmt` (rust-lang/rust-by-example#1144)
- fix typo (rust-lang/rust-by-example#1142)
- Update syntax for 2018 Edition (rust-lang/rust-by-example#1136)
- Added two missing full stops (rust-lang/rust-by-example#1138)
- Removed unnecessary spaces before macro designators in macros/dry (rust-lang/rust-by-example#1139)
- fix install mdbook command (rust-lang/rust-by-example#1128)
- Changed word `function` to `type` in comment of fn area (rust-lang/rust-by-example#1132)
- Added two missing backticks in generics/multi_bounds (rust-lang/rust-by-example#1129)
- Fixed small logic error in error/option_unwrap/and_then (rust-lang/rust-by-example#1127)
- Fix typo (rust-lang/rust-by-example#1125)
- The code of conduct link was dead. I fixed it. (rust-lang/rust-by-example#1122)
- I added a space in the Display fmt for Complex (rust-lang/rust-by-example#1123)
- Fix Rust install link in the index (rust-lang/rust-by-example#1124)
- Update cargo conventions section (rust-lang/rust-by-example#1121)
- Fixed curly braces in the `To and from Strings` chapter to be parentheses (rust-lang/rust-by-example#1120)
- Edit a typo (rust-lang/rust-by-example#1119)
- Fixes rust-lang/rust-by-example#1115 by correcting the typo from into_iterator to into_iter (rust-lang/rust-by-example#1118)
6 commits in 9e656ead82bfe869493dec82653a52e27fa6a05c..07fd3880ea0874d82b1d9ed30ad3427ec98b4e8a
2019-03-03 16:03:26 +0000 to 2019-03-27 15:40:52 +0000
- Fix test errors. (rust-embedded/book#180)
- Update qemu.md (rust-embedded/book#170)
- Update no-std.md to remove obsolete FAQ link (rust-embedded/book#177)
- We've come a long way :) (rust-embedded/book#176)
- Correct link to team (rust-embedded/book#175)
- Update some book links to their new homes. (rust-embedded/book#173)
bors [Fri, 29 Mar 2019 11:20:55 +0000 (11:20 +0000)]
Auto merge of #59303 - euclio:remove-rebuild-trigger, r=cuviper
replace llvm-rebuild-trigger with submodule commit hash
As mentioned in #59285.
This PR removes the need to update the `llvm-rebuild-trigger` file. Instead, the latest commit hash of the appropriate LLVM submodule will be stored in the stamp file and used to detect if a build is required.
Rollup merge of #59498 - mbrubeck:write_all, r=Centril
Use 'write_all' instead of 'write' in example code
Using `write` without looping and checking the result can cause silent data loss. Example code should use `write_all` so that people don't copy this pattern. (Of course this does not include example code for docs that are specifically about the `write` method.)
projects / rust.git / log