This was added in #38072 but I can't recall why and AFAIK Cargo already handles
this. This was discovered through #42146 where passing duplicate flags was
causing problems.
Decompose Adjustment into smaller steps and remove the method map.
The method map held method callee information for:
* actual method calls (`x.f(...)`)
* overloaded unary, binary, indexing and call operators
* *every overloaded deref adjustment* (many can exist for each expression)
That last one was a historical ~~accident~~ hack, and part of the motivation for this PR, along with:
* a desire to compose adjustments more freely
* containing the autoderef logic better to avoid mutation within an inference snapshot
* not creating `TyFnDef` types which are incompatible with the original one
* i.e. we used to take a`TyFnDef`'s `for<'a> &'a T -> &'a U` signature and instantiate `'a` using a region inference variable, *then* package the resulting `&'b T -> &'b U` signature in another `TyFnDef`, while keeping *the same* `DefId` and `Substs`
* to fix#3548 by explicitly writing autorefs for the RHS of comparison operators
Individual commits tell their own story, of "atomic" changes avoiding breaking semantics.
Future work based on this PR could include:
* removing the signature from `TyFnDef`, now that it's always "canonical"
* some questions of variance remain, as subtyping *still* treats the signature differently
* moving part of the typeck logic for methods, autoderef and coercion into `rustc::traits`
* allowing LUB coercions (joining multiple expressions) to "stack up" many adjustments
* transitive coercions (e.g. reify or unsize after multiple steps of autoderef)
r? @nikomatsakis
rustbuild: Fix copying duplicate crates into the sysroot
After compiling a project (e.g. libstd, libtest, or librustc) rustbuild needs to
copy over all artifacts into the sysroot of the compiler it's assembling.
Unfortunately rustbuild doesn't know precisely what files to copy! Today it has
a heuristic where it just looks at the most recent version of all files that
look like rlibs/dylibs and copies those over. This unfortunately leads to bugs
with different versions of the same crate as seen in #42261.
This commit updates rustbuild's strategy of copying artifacts to work off the
list of artifacts produced by `cargo build --message-format=json`. The build
system will now parse json messages coming out of Cargo to watch for files being
generated, and then it'll only copy over those precise files.
Note that there's still a bit of weird logic where Cargo prints that it's
creating `libstd.rlib` where we actually want `libstd-xxxxx.rlib`, so we still
do a bit of "most recent file" probing for those. This commit should take care
of the crates.io dependency issues, however, as they're all copied over
precisely.
Closes#42261
ARMv5 needs +strict-align
Without that flag, LLVM generates unaligned memory access instructions, which are not allowed on ARMv5.
For example, the 'hello world' example from `cargo --new` failed with:
```
$ ./hello
Hello, world!
thread 'main' panicked at 'assertion failed: end <= len', src/libcollections/vec.rs:1113
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
I traced this error back to the following assembler code in `BufWriter::flush_buf`:
```
6f44: e28d0018 add r0, sp, #24
[...]
6f54: e280b005 add fp, r0, #5
[...]
7018: e5cd001c strb r0, [sp, #28]
701c: e1a0082a lsr r0, sl, #16
7020: 03a01001 moveq r1, #1
7024: e5cb0002 strb r0, [fp, #2]
7028: e1cba0b0 strh sl, [fp]
```
Note that `fp` points to `sp + 29`, so the three `str*`-instructions should fill up a 32bit - value at `sp + 28`, which is later used as the value `n` in `Ok(n) => written += n`. This doesn't work on ARMv5 as the `strh` can't write to the unaligned contents of `fp`, so the upper bits of `n` won't get cleared, leading to the assertion failure in Vec::drain.
With `+strict-align`, the code works as expected.
Add the RLS to .exe, .msi, and .pkg installers
This directly addresses issue #42157, adding the RLS as a non-default component in the mentioned installers. The windows installers appear to have the right functionality added, but I don't have a machine that runs OSX, so it would be great if someone could test whether my .pkg commit adds the RLS correctly. The final commit also fixes some formatting issues I'd noticed while working on the installers, but I don't know if that's within the scope of this PR, so input would be appreciated.
Upgrade ProjectionTy's Name to a DefId
Part of #42171, in preparation for downgrading the contained `TraitRef` to
only its `substs`.
Some inline questions in the diff. Look for `FIXME(tschottdorf)`. These comments
should be addressed before merging.
rustdoc: Cleanup associated const value rendering
Rather than (ab)using Debug for outputting the type in plain text use the
alternate format parameter which already does exactly that. This fixes
type parameters for example which would output raw HTML.
Also cleans up adding parens around references to trait objects.
Rather than (ab)using Debug for outputting the type in plain text use the
alternate format parameter which already does exactly that. This fixes
type parameters for example which would output raw HTML.
Also cleans up adding parens around references to trait objects.
RangeFrom should have an infinite size_hint
Before,
```rust
(0..).take(4).size_hint() == (0, Some(4))
```
With this change,
```rust
(0..).take(4).size_hint() == (4, Some(4))
```
Clarify the docs for align_of and its variants
It's okay to have unaligned raw pointers and then use `ptr::write_unaligned` and `ptr::read_unaligned`.
However, using unaligned `&T` and `&mut T` would be undefined behavior.
The current documentation seems to indicate that everything has to be aligned, but in reality only references do. This PR changes the text of docs accordingly.
r? @sfackler
Explain why a closure is `FnOnce` in closure errors.
Issue: #42065
@nikomatsakis Am I going the right direction with this?
~~I am stuck in a few bits:~~
~~1. How to trace the code to get the upvar instead of the original variable's span?~~
~~2. How to find the node id of the upvar where the move occured?~~
Clarify docs on implementing Into.
This was suggested by @dtolnay in #40380.
This explicitly clarifies in what circumstances you should implement `Into` instead of `From`.
