Update RLS
This includes https://github.com/rust-lang/rls/pull/1482 which should finally fix the spurious tests RLS in Rust CI (test-pass -> test-fail).
r? @oli-obk
cc @ehuss
Currently `rustfmt` is excluded from the "don't build dependencies
twice" check but it's currently building dependencies twice! Namely big
dependencies like `rustc-ap-syntax` are built once for rustfmt and once
for the RLS. This commit includes `rustfmt` in these checks and then
fixes the resulting feature mismatches for winapi.
This adds a new diagnostic writer `AnnotateRsEmitterWriter` that uses
the [`annotate-snippet`][as] library to print out the human readable
diagnostics.
The goal is to eventually switch over to using the library instead of
maintaining our own diagnostics output.
This commit does *not* add all the required features to the new
diagnostics writer. It is only meant as a starting point so that other
people can contribute as well.
[as]: https://github.com/rust-lang/annotate-snippets-rs
Rollup of 13 pull requests
Successful merges:
- #61135 (Fix documentation of `Rc::make_mut` regarding `rc::Weak`.)
- #61404 (miri unsizing: fix projecting into a field of an operand)
- #61409 (Fix an ICE with a const argument in a trait)
- #61413 (Re-implement async fn drop order lowering )
- #61419 (Add an unusual-conversion example to to_uppercase)
- #61420 (Succinctify splice docs)
- #61444 (Suggest using `as_ref` on `*const T`)
- #61446 (On TerminatorKind::DropAndReplace still handle unused_mut correctly)
- #61485 (azure: retry s3 upload if it fails)
- #61489 (ci: Reenable step timings on AppVeyor)
- #61496 (Do not panic in tidy on unbalanced parentheses in cfg's)
- #61497 (Treat 0 as special value for codegen-units-std)
- #61499 (Add regression test for existential type ICE #53457)
Failed merges:
r? @ghost
rustc: remove Res::Upvar.
By keeping track of the current "`body_owner`" (the `DefId` of the current fn/closure/const/etc.) in several passes, `Res::Upvar` and `hir::Upvar` don't need to contain contextual information about the closure.
By leveraging [`indexmap`](https://docs.rs/indexmap), the list of upvars for a given closure can now also be queried, to check whether a local variable is a closure capture, and so `Res::Upvar` can be merged with `Res::Local`.
And finally, the `tcx.upvars(...)` query now collects upvars from HIR, without relying on `rustc_resolve`.
r? @petrochenkov cc @varkor @davidtwco
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
tidy: don't short-circuit on license error
If there is more than one license error, tidy would only print the first
error. This changes it so that all license errors are printed.
Add Azure Pipelines configuration
Huge thanks to ＠johnterickson and ＠willsmythe for writing the initial config! ❤️
I applied some changes to the initial config and disabled most of the builders since we're not going to run all of them during the initial step for the evaluation.
[More details about our plans for the Azure Pipelines evaluation.](https://internals.rust-lang.org/t/update-on-the-ci-investigation/10056)
r? ＠alexcrichton ＠kennytm
cc ＠rust-lang/infra ＠ethomson ＠rylev
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687.
First draft, feedback welcome.
Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them.
# Changes
## src\bootstrap
- test.rs: Run CDB debuginfo tests on MSVC targets
## src\test\debuginfo
- issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?)
- pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests.
- should-fail.rs: Add CDB tests.
## src\tools\compiletest:
- Added "-cdb" option
- Added Mode::DebugInfoCdb ("debuginfo-cdb")
- Added run_debuginfo_cdb_test[_no_opt]
- Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means.
- Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\\*\cdb.exe"
- Ignore CDB tests if CDB not found.
# Issues
- `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%`
- `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist)
- DSTs (array/string slices) which work in VS & VS Code fail in CDB.
- I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations.
# Reference
CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
Installing just "Debugging Tools for Windows" is sufficient.
CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here:
0ffc573110/appveyor.yml (L227)
CDB commands and command line reference:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
The one locked here has a dependency on an old enough `cmake` crate that
it's not detecting visual studio correctly. Let's update webrender which
updates `cmake` which should be able to detect Visual Studio correctly.
- Don't add path_buf_capacity feature.
- Convert `find_cdb` to early return style, reducing indentation
- Simplify `compute_stamp_hash` for CDB to just hash it's path, if any.
Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files.
While this only tests CDB, that test coverage should help for all of them.
CHANGES
src\bootstrap
- test.rs: Run CDB debuginfo tests on MSVC targets
src\test\debuginfo
- issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?)
- pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests.
- should-fail.rs: Add CDB tests.
src\tools\compiletest:
- Added "-cdb" option
- Added Mode::DebugInfoCdb ("debuginfo-cdb")
- Added run_debuginfo_cdb_test[_no_opt]
- Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means.
- Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe"
- Ignore CDB tests if CDB not found.
ISSUES
- `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%`
- `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist)
- DSTs (array/string slices) which work in VS & VS Code fail in CDB.
- I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations.
REFERENCE
CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
Installing just "Debugging Tools for Windows" is sufficient.
CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here:
0ffc573110/appveyor.yml (L227)
CDB commands and command line reference:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
rustdoc: set the default edition when pre-parsing a doctest
Fixes https://github.com/rust-lang/rust/issues/59313 (possibly more? i think we've had issues with parsing edition-specific syntax in doctests at some point)
When handling a doctest, rustdoc needs to parse it beforehand, so that it can see whether it declares a `fn main` or `extern crate my_crate` explicitly. However, while doing this, rustdoc doesn't set the "default edition" used by the parser like the regular compilation runs do. This caused a problem when parsing a doctest with an `async move` block in it, since it was expecting the `move` keyword to start a closure, not a block.
This PR changes the `rustdoc::test::make_test` function to set the parser's default edition while looking for a main function and `extern crate` statement. However, to do this, `make_test` needs to know what edition to set. Since this is also used during the HTML rendering process (to make playground URLs), now the HTML renderer needs to know about the default edition. Upshot: rendering standalone markdown files can now accept a "default edition" for their doctests with the `--edition` flag! (I'm pretty sure i waffled around how to set that a long time ago when we first added the `--edition` flag... `>_>`)
I'm posting this before i stop for the night so that i can write this description while it's still in my head, but before this merges i want to make sure that (1) the `rustdoc-ui/failed-doctest-output` test still works (i expect it doesn't), and (2) i add a test with the sample from the linked issue.
Switch to SPDX 2.1 license expression
[According to the Cargo Reference:](https://doc.rust-lang.org/cargo/reference/manifest.html)
> This is an SPDX 2.1 license expression for this package. Currently crates.io will validate the license provided against a whitelist of known license and exception identifiers from the SPDX license list 2.4. Parentheses are not currently supported.
>
> Multiple licenses can be separated with a \`/\`, although that usage is deprecated. Instead, use a license expression with AND and OR operators to get more explicit semantics.
The notation with slashes is deprecated in favor of explicit AND or OR.
As I understand it, Rust's license is MIT *OR* Apache-2.0 matching the meaning of *OR* defined by [SPDX Specification 2.1](https://spdx.org/spdx-specification-21-web-version):
> If presented with a choice between two or more licenses, use the disjunctive binary "OR" operator to construct a new license expression, where both the left and right operands are valid license expression values.
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?
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
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
````
