Update rustc book CLI docs.
This adds a little detail (and missing flags) to the rustc book. There is still a lot of information missing, but this seemed like a good step to expanding it.
Include expression to wait for to the span of Await
Currently the span of `await!` only includes itself:
```rust
await!(3);
// ^^^^^
```
This PR changes it so that the span holds the whole `await!` expression:
```rust
await!(3);
// ^^^^^^^^^
string: implement From<&String> for String
Allow Strings to be created from borrowed Strings. This is mostly
to make things like passing `&String` to an `impl Into<String>`
parameter frictionless.
Fixes#59827.
Move token tree related lexer state to a separate struct
Just a types-based refactoring.
We only used a bunch of fields when tokenizing into a token tree, so let's move them out of the base lexer
Remove bitrig support from rust
Resolves#60743
using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?).
There's also this file 5b8e99bb61/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
Rollup of 9 pull requests
Successful merges:
- #60130 (Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators)
- #60443 (as_ptr returns a read-only pointer)
- #60444 (forego caching for all participants in cycles, apart from root node)
- #60719 (Allow subdirectories to be tested by x.py test)
- #60780 (fix Miri)
- #60788 (default to $ARCH-apple-macosx10.7.0 LLVM triple for darwin targets)
- #60799 (Allow late-bound regions in existential types)
- #60808 (Improve the "must use" lint for `Future`)
- #60819 (submodules: update clippy from 3710ec59 to ad3269c4)
Failed merges:
r? @ghost
submodules: update clippy from 3710ec59 to ad3269c4
Changes:
````
Rustfmt all the things
Clippy dogfood
Update for compiletest changes
Use symbols instead of strings
Rustup to rustc 1.36.0-nightly (1764b2972 2019-05-12)
Add regression test for identity_conversion FP
UI test cleanup: Extract many_single_char_names tests
Add tests for empty_loop lint
Add in_macro again
Rename in_macro to in_macro_or_desugar
````
r? @oli-obk
default to $ARCH-apple-macosx10.7.0 LLVM triple for darwin targets
Over in #60378, we made `rustc` switch LLVM target triples dynamically
based on the `MACOSX_DEPLOYMENT_TARGET` environment variable. This
change was made to align with `clang`'s behavior, and therefore make
cross-language LTO feasible on OS X. Otherwise, `rustc` would produce
LLVM bitcode files with a target triple of `x86_64-apple-darwin`,
`clang` would produce LLVM bitcode files with a target triple of
`x86_64-apple-macosx$VERSION`, and the linker would complain.
This change worked fine, except for one corner case: if you didn't have
`MACOSX_DEPLOYMENT_TARGET` set, and you wanted to do LTO on just Rust
code, you'd get warning messages similar to:
```
warning: Linking two modules of different target triples: ' is 'x86_64-apple-macosx10.7.0' whereas 'main.7rcbfp3g-cgu.4' is 'x86_64-apple-darwin'
```
This message occurs because libstd is compiled with
`MACOSX_DEPLOYMENT_TARGET` set to 10.7. The LLVM bitcode distributed in
libstd's rlibs, then, is tagged with the target triple of
`x86_64-apple-macosx10.7.0`, while the bitcode `rustc` produces for
"user" code is tagged with the target triple of `x86_64-apple-darwin`.
It's not good to have LTO on just Rust code (probably much more common
than cross-language LTO) warn by default. These warnings also break
Cargo's testsuite.
This change defaults to acting as though `MACOSX_DEPLOYMENT_TARGET` was
set to 10.7. "user" code will then be given a target triple that is
equivalent to the target triple libstd bitcode is already using. The
above warning will therefore go away.
`rustc` already assumes that compiling without
`MACOSX_DEPLOYMENT_TARGET` means that we're compiling for a target
compatible with OS X 10.7 (e.g. that things like TLS work properly). So
this change is really just making things conform more closely to the
status quo.
(It's also worth noting that before and after this patch, compiling with
`MACOSX_DEPLOYMENT_TARGET` set to, say, 10.9, works just fine: target
triples with an "apple" version ignore OS versions when checking
compatibility, so bitcode with a `x86_64-apple-macosx10.7.0` triple works just
fine with bitcode with a `x86_64-apple-macosx10.9.0` triple.)
Allow subdirectories to be tested by x.py test
Fixes https://github.com/rust-lang/rust/issues/60718.
As far as I can tell, multiple `--test-args` flags are ignored (only the first is respected), so if you specify a subdirectory, you won't also be able to filter using `--test-args`. If you don't specify a subdirectory, `--test-args` will continue working as usual, so this is strictly an improvement on the current state of affairs.
forego caching for all participants in cycles, apart from root node
This is a targeted fix for #60010, which uncovered a pretty bad failure of our caching strategy in the face of coinductive cycles. The problem is explained in the comment in the PR on the new field, `in_cycle`, but I'll reproduce it here:
> Starts out as false -- if, during evaluation, we encounter a
> cycle, then we will set this flag to true for all participants
> in the cycle (apart from the "head" node). These participants
> will then forego caching their results. This is not the most
> efficient solution, but it addresses #60010. The problem we
> are trying to prevent:
>
> - If you have `A: AutoTrait` requires `B: AutoTrait` and `C: NonAutoTrait`
> - `B: AutoTrait` requires `A: AutoTrait` (coinductive cycle, ok)
> - `C: NonAutoTrait` requires `A: AutoTrait` (non-coinductive cycle, not ok)
>
> you don't want to cache that `B: AutoTrait` or `A: AutoTrait`
> is `EvaluatedToOk`; this is because they were only considered
> ok on the premise that if `A: AutoTrait` held, but we indeed
> encountered a problem (later on) with `A: AutoTrait. So we
> currently set a flag on the stack node for `B: AutoTrait` (as
> well as the second instance of `A: AutoTrait`) to supress
> caching.
>
> This is a simple, targeted fix. The correct fix requires
> deeper changes, but would permit more caching: we could
> basically defer caching until we have fully evaluated the
> tree, and then cache the entire tree at once.
I'm not sure what the impact of this fix will be in terms of existing crates or performance: we were accepting incorrect code before, so there will perhaps be some regressions, and we are now caching less.
As the comment above notes, we could do a lot better than this fix, but that would involve more invasive rewrites. I thought it best to start with something simple.
r? @pnkfelix -- but let's do crater/perf run
cc @arielb1
as_ptr returns a read-only pointer
Add comments to `as_ptr` methods to warn that these are read-only pointers, and writing to them is UB.
[It was pointed out](https://internals.rust-lang.org/t/as-ptr-vs-as-mut-ptr/9940) that `CStr` does not even have an `as_mut_ptr`. I originally was going to add one, but there is no method at all that would mutate a `CStr`. Was that a deliberate choice or should I add an `as_mut_ptr` (similar to [what I did for `str`](https://github.com/rust-lang/rust/pull/58200))?
Add implementations of last in terms of next_back on a bunch of DoubleEndedIterators
Provided a `DoubleEndedIterator` has finite length, `Iterator::last` is equivalent to `DoubleEndedIterator::next_back`. But searching forwards through the iterator when it's unnecessary is obviously not good for performance. I ran into this on one of the collection iterators.
I tried adding appropriate overloads for a bunch of the iterator adapters like filter, map, etc, but I ran into a lot of type inference failures after doing so.
The other interesting case is what to do with `Repeat`. Do we consider it part of the contract that `Iterator::last` will loop forever on it? The docs do say that the iterator will be evaluated until it returns None. This is also relevant for the adapters, it's trivially easy to observe whether a `Map` adapter invoked its closure a zillion times or just once for the last element.
Destabilize the `Error::type_id` function
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:
struct MyType;
impl Error for MyType {
fn type_id(&self) -> TypeId {
// Enable safe casting to `String` by accident.
TypeId::of::<String>()
}
}
This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the [security mailing list](https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70) as well as [the blog](https://blog.rust-lang.org/2019/05/13/Security-advisory.html)
This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
Changes:
````
Rustfmt all the things
Clippy dogfood
Update for compiletest changes
Use symbols instead of strings
Rustup to rustc 1.36.0-nightly (1764b2972 2019-05-12)
Add regression test for identity_conversion FP
UI test cleanup: Extract many_single_char_names tests
Add tests for empty_loop lint
Add in_macro again
Rename in_macro to in_macro_or_desugar
````
Over in #60378, we made `rustc` switch LLVM target triples dynamically
based on the `MACOSX_DEPLOYMENT_TARGET` environment variable. This
change was made to align with `clang`'s behavior, and therefore make
cross-language LTO feasible on OS X. Otherwise, `rustc` would produce
LLVM bitcode files with a target triple of `x86_64-apple-darwin`,
`clang` would produce LLVM bitcode files with a target triple of
`x86_64-apple-macosx$VERSION`, and the linker would complain.
This change worked fine, except for one corner case: if you didn't have
`MACOSX_DEPLOYMENT_TARGET` set, and you wanted to do LTO on just Rust
code, you'd get warning messages similar to:
```
warning: Linking two modules of different target triples: ' is 'x86_64-apple-macosx10.7.0' whereas 'main.7rcbfp3g-cgu.4' is 'x86_64-apple-darwin'
```
This message occurs because libstd is compiled with
`MACOSX_DEPLOYMENT_TARGET` set to 10.7. The LLVM bitcode distributed in
libstd's rlibs, then, is tagged with the target triple of
`x86_64-apple-macosx10.7.0`, while the bitcode `rustc` produces for
"user" code is tagged with the target triple of `x86_64-apple-darwin`.
It's not good to have LTO on just Rust code (probably much more common
than cross-language LTO) warn by default. These warnings also break
Cargo's testsuite.
This change defaults to acting as though `MACOSX_DEPLOYMENT_TARGET` was
set to 10.7. "user" code will then be given a target triple that is
equivalent to the target triple libstd bitcode is already using. The
above warning will therefore go away.
`rustc` already assumes that compiling without
`MACOSX_DEPLOYMENT_TARGET` means that we're compiling for a target
compatible with OS X 10.7 (e.g. that things like TLS work properly). So
this change is really just making things conform more closely to the
status quo.
(It's also worth noting that before and after this patch, compiling with
`MACOSX_DEPLOYMENT_TARGET` set to, say, 10.9, works just fine: target
triples with an "apple" version ignore OS versions when checking
compatibility, so bitcode with a `x86_64-apple-macosx10.7.0` triple works just
fine with bitcode with a `x86_64-apple-macosx10.9.0` triple.)
