Oliver Schneider [Mon, 17 Jul 2017 08:16:08 +0000 (10:16 +0200)]
Move resolve diagnostic instability to compile-fail
The produced paths aren't stable between builds, since
reporting paths inside resolve, before resolve is finished
might produce paths resolved to type aliases instead of
the concrete type.
Compile-fail tests can match just parts of messages, so they
don't "suffer" from this issue.
This is just a workaround, the instability should be fixed
in the future.
Auto merge of #43258 - petrochenkov:cbabort, r=alexcrichton
Compile `compiler_builtins` with `abort` panic strategy
A workaround for https://github.com/rust-lang/rust/issues/43095
In case this causes unexpected consequences, I use a simpler workaround locally:
```diff
--- a/src/bootstrap/bin/rustc.rs
+++ b/src/bootstrap/bin/rustc.rs
@@ -175,7 +175,9 @@ fn main() {
}
if let Ok(s) = env::var("RUSTC_CODEGEN_UNITS") {
- cmd.arg("-C").arg(format!("codegen-units={}", s));
+ if crate_name != "compiler_builtins" {
+ cmd.arg("-C").arg(format!("codegen-units={}", s));
+ }
}
Auto merge of #43055 - est31:stabilize_float_bits_conv, r=sfackler
Stabilize float_bits_conv for Rust 1.21
Stabilizes the `float_bits_conv` lib feature for the 1.20 release of Rust. I've initially implemented the feature in #39271 and later made PR #43025 to output quiet NaNs even on platforms with different encodings, which seems to have been the only unresolved issue of the API.
Due to PR #43025 being only applied to master this stabilisation can't happen for Rust 1.19 through the usual "stabilisation on beta" system that is being done for library APIs.
Auto merge of #43252 - vbrandl:doc/default-values, r=GuillaumeGomez
Document default values for primitive types
All primitive types implement the `Default` trait but the documentation just says `Returns the "default value" for a type.` and doesn't give a hint about the actual default value. I think it would be good to document the default values in a proper way.
I changed the `default_impl` macro to accept a doc string as a third parameter and use this string to overwrite the documentation of `default()` for each primitive type.
The generated documentation now looks like this:
Auto merge of #43207 - alexcrichton:update-cargo, r=nikomatsakis
Update the `cargo` submodule
Notably pull in an update to the `jobserver` crate to have Cargo set the
`CARGO_MAKEFLAGS` environment variable instead of the `MAKEFLAGS` environment
variable.
I changed the interface of `__thread_local_inner!`, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.
Rollup merge of #43159 - cuviper:ptr-swap-simd, r=arielb1
Disable big-endian simd in swap_nonoverlapping_bytes
This is a workaround for #42778, which was git-bisected to #40454's
optimizations to `mem::swap`, later moved to `ptr` in #42819. Natively
compiled rustc couldn't even compile stage1 libcore on powerpc64 and
s390x, but they work fine without this `repr(simd)`. Since powerpc64le
works OK, it seems probably related to being big-endian.
The underlying problem is not yet known, but this at least makes those
architectures functional again in the meantime.
Rollup merge of #43074 - SimonSapin:iter, r=aturon
Forward more Iterator methods
This allows in more cases to take advantage of specific (possibly more optimized) impls of these methods, rather than the default one defined for all `Iterator`s.
I also wanted to do this for `&mut I` and `Box<I>`, but that didn’t compile for two reasons:
* To make the trait object-safe, generic methods (e.g. that take a closure parameter) have a `where Self: Sized` bound. But e.g. `Box<I>: Sized` does not imply `I: Sized`, and adding an additional bound in the impl is not allowed. Some for of specialization would be needed here.
* With e.g. a `F: FnMut(Self::Item) -> bool` bound and a `type Item = I::Item` associated types, I got errors like `F does not implement FnMut(I::Item) -> bool`. This looks like a limitation in the trait resolution system not recognizing that `Self::Item == I::Item` or "propagating" that fact to `FnMut` bounds.
Auto merge of #43184 - nikomatsakis:incr-comp-anonymize-trait-selection, r=michaelwoerister
integrate anon dep nodes into trait selection
Use anonymous nodes for trait selection. In all cases, we use the same basic "memoization" strategy:
- Store the `DepNodeIndex` in the slot along with value.
- If value is present, return it, and add a read of the dep-node-index.
- Else, start an anonymous task, and store resulting node.
We apply this strategy to a number of caches in trait selection:
- The "trans" caches of selection and projection
- The "evaluation" cache
- The "candidate selection" cache
In general, for our cache strategy to be "dep-correct", the computation of the value is permitted to rely on the *value in the key* but nothing else. The basic argument is this: in order to look something up, you have to produce the key, and to do that you must have whatever reads were needed to create the key. Then, you get whatever reads were further needed to produce the value. But if the "closure" that produced the value made use of *other* environmental data, not derivable from the key, that would be bad -- but that would **also** suggest that the cache is messed up (though it's not proof).
The structure of these caches do not obviously prove that the correctness criteria are met, and I aim to address that in further refactorings. But I *believe* it to be the case that, if we assume that the existing caches are correct, there are also no dependency failures (in other words, if there's a bug, it's a pre-existing one). Specifically:
- The trans caches: these take as input just a `tcx`, which is "by definition" not leaky, the `trait-ref` etc, which is part of the key, and sometimes a span (doesn't influence the result). So they seem fine.
- The evaluation cache:
- This computation takes as input the "stack" and has access to the infcx.
- The infcx is a problem -- would be better to take the tcx -- and this is exactly one of the things I plan to improve in later PRs. Let's ignore it for now. =)
- The stack itself is also not great, in that the *key* only consists of the top-entry in the stack.
- However, the stack can cause a problem in two ways:
- overflow (we panic)
- cycle check fails (we do not update the cache, I believe)
- The candidate selection cache:
- as before, takes the "stack" and has access to the infcx.
- here it is not as obvious that we avoid caching stack-dependent computations. However, to the extent that we do, this is a pre-existing bug, in that we are making cache entries we shouldn't.
- I aim to resolve this by -- following the chalk-style of evaluation -- merging candidate selection and evaluation.
- The infcx is a problem -- would be better to take the tcx -- and this is exactly one of the things I plan to improve in later PRs. Let's ignore it for now. =)
- The stack itself is also not great, in that the *key* only consists of the top-entry in the stack.
- Moreover, the stack would generally just introduce ambiguities and errors anyhow, so that lessens the risk.
Anyway, the existing approach to handle dependencies in the trait code carries the same risks or worse, so this seems like a strict improvement!
Auto merge of #43174 - RalfJung:refactor-ty, r=nikomatsakis
Refactor: {Lvalue,Rvalue,Operand}::ty only need the locals' types, not the full &Mir
I am writing code that needs to call these `ty` methods while mutating MIR -- which is impossible with the current API.
Even with the refactoring the situation is not great: I am cloning the `local_decls` and then passing the clone to the `ty` methods. I have to clone because `Mir::basic_blocks_mut` borrows the entire `Mir` including the `local_decls`. But even that is better than not being able to get these types at all...
Auto merge of #43175 - tlively:wasm-split-bots, r=alexcrichton
Split old and experimental wasm builders
#42784 introduced configuration errors in the wasm builder by mixing different versions of the tools. This PR separates the wasm32-unknown-emscripten and wasm32-experimental-emscripten builders to resolve these errors.
Alex Crichton [Thu, 13 Jul 2017 05:22:25 +0000 (22:22 -0700)]
Update the `cargo` submodule
Notably pull in an update to the `jobserver` crate to have Cargo set the
`CARGO_MAKEFLAGS` environment variable instead of the `MAKEFLAGS` environment
variable.
Steve Klabnik [Thu, 13 Jul 2017 14:45:18 +0000 (10:45 -0400)]
Rollup merge of #43157 - zackmdavis:mail_map, r=steveklabnik
update .mailmap
It's nice to have an up-to-date .mailmap so that contributor listings (like those provided by `git shortlog` or http://thanks.rust-lang.org/) don't split the same author's contributions across two or more variations of their name.
Affected contributors—
@Aaronepower (3 commits as "Aaron Power", 1 as "Aaronepower")
@djrollins (5 commits as "Daniel J Rollins", 1 as "Daniel Rollins")
@eddyb (345 commits as "Eduard-Mihai Burtescu", 678 as "Eduard Burtescu", assuming former is canonical based on recency and GitHub profile display name)
@edunham (1 more recent commit contradicts existing .mailmap entry)
@GuillaumeGomez (942 commits as "Guillaume Gomez", 55 commits as "ggomez", 22 commits as "GuillaumeGomez")
@jonathandturner (362 commits as "Jonathan Turner", 1 as "jonathandturner")
@Mark-Simulacrum (248 commits as "Mark Simulacrum", 97 "Mark-Simulacrum")
@fiveop (1 commit each as "Philipp Matthias Schäfer" and "Philipp Matthias Schaefer", assuming former is canonical based on GitHub profile display name)
@shyaamsundhar (1 commit as "Shyam Sundar B", 3 as ShyamSundarB, assuming former is canonical based on recency)
@steveklabnik (1634 commits as "Steve Klabnik", 41 as "steveklabnik")
Steve Klabnik [Thu, 13 Jul 2017 14:45:16 +0000 (10:45 -0400)]
Rollup merge of #42926 - Havvy:doc-path-ext, r=steveklabnik
Document what happens on failure in path ext is_file is_dir
r? @steveklabnik
Also, what other ways could there be an error that gets discarded and returns false? Should we list them all? Should we say that any errors trying to access the metadata at that path causes it to return false, even if there might be a file or directory there?
Should I add a See also link to the original functions that do return Results?
Auto merge of #43158 - PlasmaPower:thread-local-try-with, r=alexcrichton
Thread local try with
https://github.com/rust-lang/rfcs/pull/2030 was turned into this PR (the RFC was closed, but it looks like just a PR should be good).
See also: state stabilization issue: #27716
`try_with` is used in two places in std: stdio and thread_info. In stdio, it would be better if the result was passed to the closure, but in thread_info, it's better as is where the result is returned from the function call. I'm not sure which is better, but I prefer the current way as it better represents the scope.
Auto merge of #43129 - Ophirr33:master, r=alexcrichton
Updated docker images to share scripts
Attempts to resolve #42201. I managed to pull out five scripts (android-base-apt-get, ubuntu16-apt-get, make3, rustbuild-setup, and crosstool-ng). Let me know if there's more I can do or if I should change some names.
r? @malbarbo
Mark Simulacrum [Wed, 12 Jul 2017 12:58:48 +0000 (06:58 -0600)]
Rollup merge of #43136 - jgallag88:bufWriterDocs, r=steveklabnik
Add warning to BufWriter documentation
When using `BufWriter`, it is very easy to unintentionally ignore errors, because errors which occur when flushing buffered data when the `BufWriter` is dropped are ignored. This has been noted in a couple places: #32677, #37045.
There has been some discussion about how to fix this problem in #32677, but no solution seems likely to land in the near future. For now, anyone who wishes to have robust error handling must remember to manually call `flush()` on a `BufWriter` before it is dropped. Until a permanent fix is in place, it seems worthwhile to add a warning to that effect to the documentation.
Mark Simulacrum [Wed, 12 Jul 2017 12:58:46 +0000 (06:58 -0600)]
Rollup merge of #43098 - alexcrichton:more-proc-macro, r=jseyfried
Add `isize` and `usize` constructors to Literal
This commit fills out the remaining integer literal constructors on the
`proc_macro::Literal` type with `isize` and `usize`. (I think these were just
left out by accident)
Mark Simulacrum [Wed, 12 Jul 2017 12:58:45 +0000 (06:58 -0600)]
Rollup merge of #43011 - qnighy:unsized-tuple-impls, r=aturon
Implement Eq/Hash/Debug etc. for unsized tuples.
As I mentioned in [the comment in #18469](https://github.com/rust-lang/rust/issues/18469#issuecomment-306767422), the implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, `Debug`, `Hash` can be generalized to unsized tuples.
This is consistent with the `derive` behavior for unsized structs.
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Default, Hash)]
struct MyTuple<X, Y, Z: ?Sized>(X, Y, Z);
fn f(x: &MyTuple<i32, i32, [i32]>) {
x == x;
x < x;
println!("{:?}", x);
}
```
Questions:
- Need an RFC?
- Need a feature gate? I don't think it does because the unsized tuple coercion #42527 is feature-gated.
- I changed `builder.field($name);` into `builder.field(&$name);` in the `Debug` implementation to pass compilation. This won't affect the behavior because `Debug for &'a T` is a mere redirection to `Debug for T`. However, I don't know if it affects code size / performance.
Mark Simulacrum [Wed, 12 Jul 2017 12:58:44 +0000 (06:58 -0600)]
Rollup merge of #42826 - Yorwba:type-mismatch-same-absolute-paths, r=arielb1
Note different versions of same crate when absolute paths of different types match.
The current check to address #22750 only works when the paths of the mismatched types relative to the current crate are equal, but this does not always work if one of the types is only included through an indirect dependency. If reexports are involved, the indirectly included path can e.g. [contain private modules](https://github.com/rust-lang/rust/issues/22750#issuecomment-302755516).
This PR takes care of these cases by also comparing the *absolute* path, which is equal if the type hasn't moved in the module hierarchy between versions. A more coarse check would be to compare only the crate names instead of full paths, but that might lead to too many false positives.
Additionally, I believe it would be helpful to show where the differing crates came from, i.e. the information in `rustc::middle::cstore::CrateSource`, but I'm not sure yet how to nicely display all of that, so I'm leaving it to a future PR.
Auto merge of #42897 - Mark-Simulacrum:pretty-print-refactor, r=jseyfried
Refactor pretty printing slightly
This doesn't introduce any functional changes (that I'm aware of). The primary intention here is to clean up the code a little. Each commit is intended to stand alone, reviewing commit-by-commit may be easiest.
Auto merge of #43107 - michaelwoerister:less-span-info-in-debug, r=nikomatsakis
incr.comp.: Don't include span information in the ICH of type definitions
This should improve some of the `regex` tests on perf.rlo. Not including spans into the ICH is harmless until we also cache warnings. To really solve the problem, we need to do more refactoring (see #43088).
Auto merge of #42936 - steveklabnik:update-mdbook, r=alexcrichton
update crate dependencies
I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
I am not sure if updating this much stuff is considered a Good Idea or not; happy to figure out how to make it smaller if someone can help me figure out how to use x.py to do it.
Mark Simulacrum [Sun, 25 Jun 2017 12:38:13 +0000 (06:38 -0600)]
Refactor cur_cmnt_and_lit away.
The literal index was increased in only next_lit, so it isn't
necessary: code now uses an iterator. The cur_cmnt field is also moved
to be increased in print_comment instead of after each call to
print_comment.
projects / rust.git / log