Add contribution instructions to stdlib docs
Generally programming language docs have instructions on how to contribute changes.
I couldn't find any in the rust docs, so I figured I'd add an instructions section, let me know if this belongs somewhere else!
```rust
error[E0072]: recursive type `X` has infinite size
--> file.rs:10:1
|
10 | struct X {
| ^^^^^^^^ recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `X` representable
```
vs
```rust
error[E0072]: recursive type `X` has infinite size
--> file.rs:10:1
|
10 | struct X {
| _^ starting here...
11 | | x: X,
12 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `X` representable
```
Add the RLS as a submodule and build a package out of it
r? @brson (and cc @alexcrichton) Please review closely, I am not at all convinced I've done the right things here. I did run `x.py dist` and it makes an rls package which looks right to my eyes, but I haven't tested on non-linux platforms nor am I really sure what it should look like.
This does not attempt to run tests for the RLS yet.
When we are generalizing a super/sub-type, we have to replace type
variables with a fresh variable (and not just region variables). So if
we know that `Box<?T> <: ?U`, for example, we instantiate `?U` with
`Box<?V>` and then relate `Box<?T>` to `Box<?V>` (and hence require that
`?T <: ?V`).
This change has some complex interactions, however:
First, the occurs check must be updated to detect constraints like `?T
<: ?U` and `?U <: Box<?T>`. If we're not careful, we'll create a
never-ending sequence of new variables. To address this, we add a second
unification set into `type_variables` that tracks type variables related
through **either** equality **or** subtyping, and use that during the
occurs-check.
Second, the "fudge regions if ok" code was expecting no new type
variables to be created. It must be updated to create new type variables
outside of the probe. This is relatively straight-forward under the new
scheme, since type variables are now independent from one another, and
any relations are moderated by pending subtype obliations and so forth.
This part would be tricky to backport though.
cc #18653
cc #40951
In some specific cases, the new scheme was failing to learn as much from
a LUB/GLB operaiton as the old code, which caused coercion to go awry. A
slight ordering hack fixes this.
In some cases, we give multiple primary spans, in which case we would
report one `//~` annotation per primary span. That was very confusing
because these things are reported to the user as a single error.
UI tests would be better here.
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.
Make sccache a bit quieter
...and remove the single mention of `SCCACHE_LOG_LEVEL` that would only take effect on Docker (i.e. Linux) builds since it had no effect anyway (because [`RUST_LOG` takes priority](ec10cdb2dd/src/main.rs (L124-L128))).
r? @frewsxcv
Implement optimization fuel and re-enable struct field reordering
See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.
This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.
It also turns field reordering back on. There is no way to test this feature without something consuming fuel. We can roll this back if we want, but then the optimization fuel bits will be dead code.
The one notable absence from this PR is a test case. I'm not sure how to do one that's worth having. The only thing I can think of to test is `-Z fuel=foo=0`. The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed. If someone has a useful proposal for a good test, I certainly want to add one.
* Use the right version when building combined installer
* Update dependencies of rls as it depends on rustc and plugins
* Fix build-manifest and the versions it uses for the rls
Reduce str transmutes, add mut versions of methods.
When I was working on the various parts involved in #40380 one of the comments I got was the excess of transmutes necessary to make the changes work. This is part of a set of multiple changes I'd like to offer to fix this problem.
I think that having these methods is reasonable because they're already possible via transmutes, and it makes the code that uses them safer. I can also add `pub(crate)` to these methods for now if the libs team would rather not expose them to the public without an RFC.
