Auto merge of #41354 - alexcrichton:tool-no-debug, r=aturon
Disable debuginfo when compiling tools
Currently the Cargo binary has jumped from 14M to 34M on the beta channel, which
appears to be due to the fact that we're compiling tools with debug information
inside them. This additionally means that the `rls` binary is 62M right now!
This wasn't an intentional change, so be sure to disable debuginfo when
compiling tools as it's just intended for the standard library and compile for
now.
Auto merge of #41325 - eddyb:isolate-snapshots-for-good, r=arielb1
Ban registering obligations during InferCtxt snapshots.
Back in #33852, a flag was added to `InferCtxt` to prevent rolling back a snapshot if obligations were added to some `FulfillmentContext` during the snapshot, to prevent leaking fresh inference variables (created during that snapshot, so their indices would get reused) in obligations, which could ICE or worse.
But that isn't enough in the long run, as type-checking ends up relying on success implying that eager side-effects are fine, and while stray obligations *do* get caught nowadays, those errors prevent, e.g. the speculative coercions from #37658, which *have to* be rolled back *even* if they succeed.
We can't just allow those obligations to stay around though, because we end up, again, in ICEs or worse.
Instead, this PR modifies `lookup_method_in_trait_adjusted` to return `InferOk` containing the obligations that `Autoderef::finalize_as_infer_ok` can propagate to deref coercions.
As there shouldn't be *anything* left that registers obligations during snapshots, it's completely banned.
Auto merge of #41170 - Nashenas88:master, r=alexcrichton
Use the existing path when removing the prefix fails
This allows the use of out-of-tree paths to be specified. I found this while trying to build with a modified version of `rls-data`, which is currently pointing to a version on crates.io.
cc @alexcrichton
Also, it wasn't clear if I needed to add a test for this (or how). I didn't see any tests that took paths into consideration.
Auto merge of #41236 - cengizIO:master, r=nikomatsakis
Move E0101 and E0102 logic into new E0282 mechanism #40013
Hello there!
## What's this?
Previously, me and @nikomatsakis worked on error messages of uninferred locals. (#38812)
This aims to build up on that by moving certain type checks from `writeback`.
With this, `E0101` and `E0102` errors are getting obsoleted and no longer thrown.
They're replaced with customized versions of `E0282`s instead.
## Sample Error Messages
#### `E0101` is getting converted into:
```rust
error[E0282]: type annotations needed
--> test.rs:2:14
|
2 | let x = |_| {};
| ^ consider giving this closure parameter a type
error: aborting due to previous error
```
#### `E0102` is getting converted into:
```rust
error[E0282]: type annotations needed
--> test.rs:2:9
|
2 | let x = [];
| ^
| |
| consider giving `x` a type
| cannot infer type for `[_; 0]`
error: aborting due to previous error
```
## Annoyances
- I think we need to change our way of type name resolving in relevant places, because that `[_; 0]` looks horrible IMHO.
- I'm not terribly happy with the note ordering of errors. So please do point to code that might help me accomplish this.
## Tests
Tests of `E0101` and `E0102` are getting converted from `compile-fail` to `ui` tests.
## Documentation
Please help me with documentation update. There are some confusing places that needed an update but I'm not sure if I did the right ones.
Please do comment on messages, layouts and other details.
## Appreciation
Huge thanks goes to @nikomatsakis for being a patient and humble mentor along this long journey. 🍻
Rollup merge of #41364 - alexcrichton:less-backtrace-prune, r=petrochenkov
std: Back out backtrace pruning logic
It was discovered #40264 that this backtrace pruning logic is a little too
aggressive, so while we figure how out to handle #40264 this commit backs out
the changes to prune frames. Note that other cosmetic changes, such as better
path printing and such remain.
Rollup merge of #41361 - arielb1:move-mir-init, r=pnkfelix
lower `move_val_init` during MIR construction
Because of its "magic" order-of-evaluation semantics, `move_val_init` must be lowered during MIR construction in order to work without needing a temporary.
Rollup merge of #41360 - nikomatsakis:incr-comp-issue-40746-visitors, r=eddyb
convert calls to `visit_all_item_likes_in_krate`
We no longer need to track the tasks in these cases since these
particular tasks have no outputs (except, potentially, errors...) and
they always execute.
This change allows to obtain an underlying invalid UTF-8 bytes without `FromUtf8Error` destruction. Such method may be useful for example in a library that attempts to save both valid and invalid UTF-8 strings in some struct and to be able to provide immutable access to it without destruction.
Personally without this change I ended with `Result<String, (Vec<u8>, Utf8Error)`, which almost copies the functionality of `FromUtf8Error`, but allows immutable view access.
Alex Crichton [Mon, 20 Mar 2017 21:13:27 +0000 (14:13 -0700)]
std: Back out backtrace pruning logic
It was discovered #40264 that this backtrace pruning logic is a little too
aggressive, so while we figure how out to handle #40264 this commit backs out
the changes to prune frames. Note that other cosmetic changes, such as better
path printing and such remain.
Auto merge of #39271 - est31:add_float_bits, r=BurntSushi
Add functions to safely transmute float to int
The safe subset of Rust tries to be as powerful as possible. While it is very powerful already, its currently impossible to safely transmute integers to floats. While crates exist that provide a safe interface, most prominently the `iee754` crate (which also inspired naming of the added functions), they themselves only use the unsafe `mem::transmute` function to accomplish this task.
Also, including an entire crate for just two lines of unsafe code seems quite wasteful.
That's why this PR adds functions to safely transmute integers to floats and vice versa, currently gated by the newly added `float_bits_conv` feature.
The functions added are no niche case. Not just `ieee754` [currently implements](https://github.com/huonw/ieee754/blob/master/src/lib.rs#L441) float to int transmutation via unsafe code but also the [very popular `byteorder` crate](https://github.com/BurntSushi/byteorder/blob/1.0.0/src/lib.rs#L258). This functionality of byteorder is in turn used by higher level crates. I only give two examples out of many: [chor](https://github.com/pyfisch/cbor/blob/a7363ea9aaf372e3d24b52414b5c76552ecc91c8/src/ser.rs#L227) and [bincode](https://github.com/TyOverby/bincode/blob/f06a4cfcb5b194e54d4997c200c75b88b6c3fba4/src/serde/reader.rs#L218).
One alternative would be to manually use functions like pow or multiplication by 1 to get a similar result, but they only work in the int -> float direction, and are not bit exact, and much slower (also, most likely the optimizer will never optimize it to a transmute because the conversion is not bit exact while the transmute is).
Niko Matsakis [Tue, 18 Apr 2017 09:57:39 +0000 (05:57 -0400)]
convert calls to `visit_all_item_likes_in_krate`
We no longer need to track the tasks in these cases since these
particular tasks have no outputs (except, potentially, errors...) and
they always execute.
Rollup merge of #41310 - eddyb:demand-const-eval, r=nikomatsakis
[on-demand] Turn monomorphic_const_eval into a proper query, not just a cache.
The error definitions and reporting logic, alongside with `eval_length` were moved to `librustc`.
Both local and cross-crate constant evaluation is on-demand now, but the latter is only used for `enum` discriminants, to replace the manual insertion into the cache which was done when decoding variants.
Rollup merge of #41262 - jonhoo:compiler-barrier-rename, r=alexcrichton
Rename compiler_barrier to compiler_fence
This addresses concerns raised following the merge of #41092. Specifically:
> The naming of these seems surprising: the multithreaded functions (and both the single and multithreaded intrinsics themselves) are fences, but this is a barrier. It's not incorrect, but the latter is both inconsistent with the existing functions and slightly confusing with another type in std (e.g., `Barrier`).
`compiler_fence` carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use in `std`.
Alex Crichton [Tue, 18 Apr 2017 00:17:11 +0000 (17:17 -0700)]
Disable debuginfo when compiling tools
Currently the Cargo binary has jumped from 14M to 34M on the beta channel, which
appears to be due to the fact that we're compiling tools with debug information
inside them. This additionally means that the `rls` binary is 62M right now!
This wasn't an intentional change, so be sure to disable debuginfo when
compiling tools as it's just intended for the standard library and compile for
now.
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured
Doc-tests sysinfo
WARNING: src/sysinfo.rs - (line 45) test will be run in the next rustdoc version. If it's not supposed to, please update your documentation and make it compliant to common mark specifications.
WARNING: src/sysinfo.rs - (line 48) test will be run in the next rustdoc version. If it's not supposed to, please update your documentation and make it compliant to common mark specifications.
running 1 test
test src/sysinfo.rs - (line 14) ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
```
Rollup merge of #41280 - QuietMisdreavus:rustdoc-toc, r=GuillaumeGomez
rustdoc: add a list of headings to the sidebar
It's another misdreavus rustdoc PR, which means it's time for Bikeshed City once again! `:3`
In an effort to aid navigation in long documentation pages, this PR adds a listing of headings to the sidebars of pages where such headings exist. For example, for structs, links to their fields, inherent methods, and trait implementations are available where applicable.
* Right now, these kinds of pages (and also unions) are the only pages that will receive the name header - pages for functions, constants, macros, etc, won't have the corresponding name in their sidebar. Should I print the name regardless and only add table-of-contents links for pages that have them? This would make them match, for example, a struct with no public fields, no methods, and no trait implementations. The latter would still have a "Struct MyStruct" line above the module contents, with no header links to speak of, whereas a function wouldn't even have "Function my\_function".
* This is only a header listing, but there has been requests to include a more-complete listing of fields/methods/traits/etc, for example in #41123.
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!
projects / rust.git / log