Auto merge of #41157 - aidanhs:aphs-debug-appveyor-cache, r=TimNN
Add a comment for disabling errexit, try to debug appveyor cache
Comments added as requested.
Also, lets add some cache debugging to appveyor. I *think* this is how to ignore errors in cmd.exe (and I did try it on my own machine), but I'm not 100% sure how appveyor runs them. In the worst case it'll fail but I guess that isn't the end of the world since the build has already failed by this point.
Auto merge of #40409 - mbrubeck:calloc, r=sfackler
Specialize Vec::from_elem to use calloc
Fixes #38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired.
I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)
Auto merge of #41286 - lukaramu:std-collections-docs, r=frewsxcv
Various improvements in std::collections docs
The meat of this PR are:
* changes to (almost all?) iterator struct docs in std::collections such that they use the standard iterator boilerplate and state where they are created
* a bunch of added links (at least as much as possible given std::collections mostly being a facade and whatnot :sweat_smile:)
* an example for `Bound`
* changed phrasing for some summary sentences to be less redundant as well as more consistant with others in the module
There also are various other fixes, e.g. removing parens from method names in the module docs, changing some imperatives to 3rd person, etc.
Rollup merge of #41125 - lukaramu:std-hash-docs, r=frewsxcv
Improve std::hash docs
Fixes #29357.
For details on what exactly I've done, see the commit descriptions.
There are some things I'm not sure about, but would like to address before merging this so the issue can be closed; any feedback on these points would really be appriciated:
* [x] ~I didn't touch the module level docs at all. On the one hand, I think they could use a short overview over the module; on the other hand, the module really isn't that big and I don't know if I could really do anything beyond just duplicating the type's summaries...~
* [x] ~I feel like the module-level examples are quite long-winded and not to the point, but I couldn't really think of anything better. Any ideas?~
* [x] ~Should `Hasher` get an example for implementing it? There is one in the module documentation, but it only "implements" it via `unimplemented!` and I'm not sure what the value of that is.~
* [x] ~Should `Hasher`'s `write_{int}` methods get examples?~
If there's anything else you'd like to see in std::hash's docs, please let me know!
Sean Griffin [Fri, 17 Mar 2017 18:16:29 +0000 (14:16 -0400)]
Put overlapping impls behind feature gate, add tests
I've added some explicit tests that negative impls are allowed to
overlap, and also to make sure that the feature doesn't interfere with
specialization. I've not added an explicit test for positive overlapping
with negative, as that's already tested elsewhere.
add 'mir' as part of the --emit flag list in rustc --help menu and man doc.
This is added because 'rustc' can now generate MIR (referencing to
"Teach rustc --emit=mir #39891").
Looks like the LinkerFlavor change introduced in #40018 accidentally uses GCC for the WebAssembly target, causing Rust to never actually pass the post link args to emscripten. This then causes the code to be compiled as asm.js instead of WebAssembly, because the Binaryen tools never run due to the missing linker argument.
Rollup merge of #41172 - Aaron1011:rustdoc-overflow, r=frewsxcv
Fix rustdoc infinitely recursing when an external crate reexports itself
Previously, rustdoc's LibEmbargoVisitor unconditionally visited the
child modules of an external crate. If a module re-exported its parent
via `pub use super::*`, rustdoc would re-walk the parent, leading to
infinite recursion.
This commit makes LibEmbargoVisitor store already visited modules in an
FxHashSet, ensuring that each module is only walked once.
Rollup merge of #40702 - mrhota:global_asm, r=nagisa
Implement global_asm!() (RFC 1548)
This is a first attempt. ~~One (potential) problem I haven't solved is how to handle multiple usages of `global_asm!` in a module/crate. It looks like `LLVMSetModuleInlineAsm` overwrites module asm, and `LLVMAppendModuleInlineAsm` is not provided in LLVM C headers 😦~~
I can provide more detail as needed, but honestly, there's not a lot going on here.
std::collections docs: Address issues that came up in PR #41286
* Bound:
* Added another example using RangeArgument to illustrate how Bound maps
to range endpoints.
* Added a note to the existing example that says that it's better to use
range syntax in most cases
* Added missing /// line
* binary_heap::PeakMut: s/Object representing/Structure wrapping
* added collections/hash_set/struct.HashSet.html to linkchecker whitelist
Christopher Serr [Fri, 14 Apr 2017 17:17:03 +0000 (19:17 +0200)]
Compile WASM as WASM instead of asm.js
Looks like the LinkerFlavor change introduced in #40018 accidentally uses GCC for the WebAssembly target, causing Rust to never actually pass the post link args to emscripten. This then causes the code to be compiled as asm.js instead of WebAssembly, because the Binaryen tools never run due to the missing linker argument.
Rollup merge of #41287 - nikomatsakis:incr-comp-refactor-trans, r=eddyb
Miscellneous refactorings of trans
This doesn't achieve any particular goal yet, but it's a collection of refactorings with the common goal of turning `SharedCrateContext` etc into stuff that we can use with on-demand and actually expect to hash in a stable fashion for incremental. Not there yet, clearly.
Rollup merge of #41279 - arielb1:adjustment-composition, r=nikomatsakis
rustc_typeck: consolidate adjustment composition
Instead of having `write_adjustment` overwrite the previous adjustment, have `apply_adjustment` compose a new adjustment on top of the previous one. This is important because `NeverToAny` adjustments can be present on expressions during coercion.
Niko Matsakis [Thu, 13 Apr 2017 19:55:48 +0000 (15:55 -0400)]
remove `LinkMeta` from `SharedCrateContext`
A number of things were using `crate_hash` that really ought to be using
`crate_disambiguator` (e.g., to create the plugin symbol names). They
have been updated.
It is important to remove `LinkMeta` from `SharedCrateContext` since it
contains a hash of the entire crate, and hence it will change
whenever **anything** changes (which would then require
rebuilding **everything**).
Various consistency and phrasing fixes in std::collections' docs
* Changed btree_map's and hash_map's Entry (etc.) docs to be consistent
* Changed VecDeque's type and module summary sentences to be consistent
with each other as well as with other summary sentences in the module
* Changed HashMap's and HashSet's summary sentences to be less redundantly
phrased and also more consistant with the other summary sentences in the
module
* Also, added an example to Bound
* Added links where possible (limited because of facading)
* Changed references to methods from `foo()` to `foo` in module docs
* Changed references to methods from `HashMap::foo` to just `foo` in
top-level docs for `HashMap` and the `default` doc for `DefaultHasher`
* Various small other fixes
Auto merge of #41227 - alexcrichton:compiletest, r=aturon
rustbuild: Fix recompilation of stage0 tools dir
This commit knocks out a longstanding FIXME in rustbuild which should correctly
recompile stage0 compiletest and such whenever libstd itself changes. The
solution implemented here was to implement a notion of "order only" dependencies
and then add a new dependency stage for clearing out the tools dir, using
order-only deps to ensure that it happens correctly.
The dependency drawing for tools is a bit wonky now but I think this'll get the
job done.
Rollup merge of #41266 - projektir:weak_docs_rc, r=alexcrichton
Updating docs for std::rc::Rc
The same changes as PR [#41240 ](https://github.com/rust-lang/rust/pull/41240), but for [`std::rc::Weak`](https://doc.rust-lang.org/std/rc/struct.Weak.html). At least, as far as I am aware, the Weak pointer is the same for both, and they're basically the same, just one is thread-safe and the other is not.
Alex Crichton [Tue, 11 Apr 2017 18:58:25 +0000 (11:58 -0700)]
rustbuild: Fix recompilation of stage0 tools dir
This commit knocks out a longstanding FIXME in rustbuild which should correctly
recompile stage0 compiletest and such whenever libstd itself changes. The
solution implemented here was to implement a notion of "order only" dependencies
and then add a new dependency stage for clearing out the tools dir, using
order-only deps to ensure that it happens correctly.
The dependency drawing for tools is a bit wonky now but I think this'll get the
job done.
Auto merge of #40367 - eddyb:naked-cruft, r=nagisa
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.
These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
* That is, if a loop branches back to it, although I'm not sure that's even valid MIR
Auto merge of #41267 - alexcrichton:fix-analysis-dist, r=alexcrichton
travis: Enable rust-analysis package for more targets
This commit enables the `rust-analysis` package to be produced for all targets
that are part of the `dist-*` suite of docker images on Travis. Currently
these packages are showing up with `available = false` in the
`channel-rust-nightly.toml` manifest where we'd prefer to have them show up for
all targets.
Unfortunately rustup isn't handling the `available = false` section well right
now, so this should also inadvertently fix the nightly regression.
Auto merge of #41009 - scottmcm:toowned-clone-into, r=alexcrichton
Add a resource-reusing method to `ToOwned`
`ToOwned::to_owned` generalizes `Clone::clone`, but `ToOwned` doesn't have an equivalent to `Clone::clone_from`. This PR adds such a method as `clone_into` under a new unstable feature `toowned_clone_into`.
Analogous to `clone_from`, this has the obvious default implementation in terms of `to_owned`. I've updated the `libcollections` impls: for `T:Clone` it uses `clone_from`, for `[T]` I moved the code from `Vec::clone_from` and implemented that in terms of this, and for `str` it's a predictable implementation in terms of `[u8]`.
Used it in `Cow::clone_from` to reuse resources when both are `Cow::Owned`, and added a test that `Cow<str>` thus keeps capacity in `clone_from` in that situation.
The obvious question: is this the right place for the method?
- It's here so it lives next to `to_owned`, making the default implementation reasonable, and avoiding another trait. But allowing method syntax forces a name like `clone_into`, rather than something more consistent like `owned_from`.
- Another trait would allow `owned_from` and could support multiple owning types per borrow type. But it'd be another single-method trait that generalizes `Clone`, and I don't know how to give it a default impl in terms of `ToOwned::to_owned`, since a blanket would mean overlapping impls problems.
I did it this way as it's simpler and many of the `Borrow`s/`AsRef`s don't make sense with `owned_from` anyway (`[T;1]:Borrow<[T]>`, `Arc<T>:Borrow<T>`, `String:AsRef<OsStr>`...). I'd be happy to re-do it the other way, though, if someone has a good solution for the default handling.
(I can also update with `CStr`, `OsStr`, and `Path` once a direction is decided.)
Windows builder croaked. This change tries to fix that by actually
calling the global_asm-defined function so the symbol doesn't get
optimized away, if that is in fact what was happening.
Additionally, we provide an empty main() for non-x86 arches.
Alex Crichton [Thu, 13 Apr 2017 03:48:18 +0000 (20:48 -0700)]
travis: Enable rust-analysis package for more targets
This commit enables the `rust-analysis` package to be produced for all targets
that are part of the `dist-*` suite of docker images on Travis. Currently
these packages are showing up with `available = false` in the
`channel-rust-nightly.toml` manifest where we'd prefer to have them show up for
all targets.
Unfortunately rustup isn't handling the `available = false` section well right
now, so this should also inadvertently fix the nightly regression.
Auto merge of #40570 - nikomatsakis:inference-subtype-through-obligation, r=arielb1
Handle subtyping in inference through obligations
We currently store subtyping relations in the `TypeVariables` structure as a kind of special case. This branch uses normal obligations to propagate subtyping, thus converting our inference variables into normal fallback. It also does a few other things:
- Removes the (unstable, outdated) support for custom type inference fallback.
- It's not clear how we want this to work, but we know that we don't want it to work the way it currently does.
- The existing support was also just getting in my way.
- Fixes #30225, which was caused by the trait caching code pretending type variables were normal unification variables, when indeed they were not (but now are).
There is one fishy part of these changes: when computing the LUB/GLB of a "bivariant" type parameter, I currently return the `a` value. Bivariant type parameters are only allowed in a very particular situation, where the type parameter is only used as an associated type output, like this:
```rust
pub struct Foo<A, B>
where A: Fn() -> B
{
data: A
}
```
In principle, if one had `T=Foo<A, &'a u32>` and `U=Foo<A, &'b u32>` and (e.g.) `A: for<'a> Fn() -> &'a u32`, then I think that computing the LUB of `T` and `U` might do the wrong thing. Probably the right behavior is just to create a fresh type variable. However, that particular example would not compile (because the where-clause is illegal; `'a` does not appear in any input type). I was not able to make an example that *would* compile and demonstrate this shortcoming, and handling the LUB/GLB was mildly inconvenient, so I left it as is. I am considering whether to revisit this or what.
I have started a crater run to test the impact of these changes.
A.J. Gardner [Thu, 30 Mar 2017 04:32:20 +0000 (23:32 -0500)]
Ensure walk_item visits GlobalAsm NodeId
Travis failures indicated the OuterVisitor#visit_item method caused a
panic. The Visitor's inner visitor actually relies on the visitor
visiting every item's NodeId. I forgot to perform that call in the
ItemGlobalAsm match arm, leading to build breakage. The fix is
simple: call visit_id(...) for ItemGlobalAsm
Auto merge of #41008 - sagebind:thread_id, r=alexcrichton
Derive Hash for ThreadId + better example
Derive `Hash` for `ThreadId` (see comments in #21507). Useful for making maps based on thread, e.g. `HashMap<ThreadId, ?>`. Also update example code for thread IDs to be more useful.