Disable git caches again
The appveyor ones aren't working anyway (I need to talk to appveyor about them being corrupt) and the travis cache is taking too long to restore and is being killed, which is sometimes causing bad things to happen because the integrity checking made assumptions that restore was atomic.
I could fix the integrity checks, but we clearly need a different approach if restore is taking too long. Let's disable it all for now.
Improve std::path docs
Fixes#29368.
This PR contains a pretty significant redistribution of some of the module docs to more appropriate places, as well as general expansion, clarification, and additional examples.
For more details, see the commit descriptions.
r? @steveklabnik
Add top level sections to the Unstable Book.
Prior to this commit, the contents of the Unstable Book were assumed to
be unstable features. This commit moves features into 'language features'
or 'library features' subsections. It also moves the 'linker_flavor'
compiler flag into a new 'Compiler Flags' subsection.
Even though it was helpful, I removed the tidy check that
cross-references the SUMMARY.md links with the Unstable Book directory
contents just because it would be difficult to maintain.
Relevant PR: https://github.com/rust-lang/rust/issues/41142.
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.
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.
r? @nikomatsakis @arielb1
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.
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. 🍻
Prior to this commit, the contents of the Unstable Book were assumed to
be unstable features. This commit moves features into 'language features'
or 'library features' subsections. It also moves the 'linker_flavor'
compiler flag into a new 'Compiler Flags' subsection.
Even though it was helpful, I removed the tidy check that
cross-references the SUMMARY.md links with the Unstable Book directory
contents just because it would be difficult to maintain.
Relevant PR: https://github.com/rust-lang/rust/issues/41142.
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.
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.
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.
cc #40746
r? @eddyb
bootstrap: Don't workaround uname -m on Darwin
This no longer manifests on any versions of OSX that I could find.
How far back is Rust officially supported? I can try to get copies to test when this behaviour changed.
(Fun fact, at a minimum the comment already lies, since the flag is `-m` :))
Improve Process::spawn with piped stdio on Redox
- Adds `dup2`, and uses it for stdio piping
- Removes `O_CLOEXEC` from piped stdio, as `dup` on Redox does not disable O_CLOEXEC
Add `as_bytes()` for `FromUtf8Error`.
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.
Instead of hard-coding the command to run, using the environment
variable `GDB_CMD` (that defaults to `gdb`) allows using a different
debugger than the default `gdb` executable.
This gives the possibility to use `cgdb` as the debugger, which provides
a nicer user interface. Note that one has to use `GDB_CMD="cgdb --"` to
use cgdb (note the trailing `--`) to let cgdb pass the proper arguments
to `gdb`.
There was a serious ARM codegen bug in LLVM that was fixed by #40779,
also backported to beta. This updates stage0 to 1.17.0-beta.3 to pick
up that change, so ARM can bootstrap natively again.
Fixes#41291
cc @arielb1
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.
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](a7363ea9aa/src/ser.rs (L227)) and [bincode](f06a4cfcb5/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).
Tracking issue: #40470
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.
[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.
r? @nikomatsakis
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`.
