| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
submodules: update clippy from 20da8f45 to 71be6f62
Changes:
````
rustup https://github.com/rust-lang/rust/pull/57428/
Remove `to_string()`s from CompilerLintFunctions
Fix comment grammar
Fix .map(..).unwrap_or_else(..) bad suggestion
add suggestions for print/write with newline lint
````
Fixes https://github.com/rust-lang/rust/issues/61578
r? @oli-obk
|
|
Changes:
````
rustup https://github.com/rust-lang/rust/pull/57428/
Remove `to_string()`s from CompilerLintFunctions
Fix comment grammar
Fix .map(..).unwrap_or_else(..) bad suggestion
add suggestions for print/write with newline lint
````
|
|
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
|
|
|
|
|
|
Changes:
````
Rustup to https://github.com/rust-lang/rust/pull/61203
rustup https://github.com/rust-lang/rust/pull/60928
rustup https://github.com/rust-lang/rust/pull/61164 (which is included in https://github.com/rust-lang/rust/pull/61274)
````
|
|
|
|
|
|
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.
|
|
Update cargo
Update cargo
14 commits in c4fcfb725b4be00c72eb9cf30c7d8b095577c280..545f354259be4e9745ea00a524c0e4c51df01aa6
2019-05-15 19:48:47 +0000 to 2019-05-23 17:45:30 +0000
- Bump to 0.38.0 (rust-lang/cargo#6979)
- cargo package: detect new empty directories (rust-lang/cargo#6973)
- Add message caching. (rust-lang/cargo#6933)
- Fix typo (rust-lang/cargo#6974)
- Set `Finished` line correctly for debug=0. (rust-lang/cargo#6971)
- Clippy fixes (rust-lang/cargo#6970)
- Remove rustdoc `can_add_color_process`. (rust-lang/cargo#6968)
- Document new `doctest` field. (rust-lang/cargo#6965)
- Update some man pages that missed --offline. (rust-lang/cargo#6964)
- add public & private prop tests. (rust-lang/cargo#6962)
- zsh completion: Pull list of commands from cargo --list (rust-lang/cargo#6956)
- Change docs "inequality" for semver requirement. (rust-lang/cargo#6963)
- Update im-rc requirement from 12.1.0 to 13.0.0 (rust-lang/cargo#6959)
- Add `doctest` field into metadata (rust-lang/cargo#6953)
|
|
Add Azure Pipelines configuration
Huge thanks to ＠johnterickson and ＠willsmythe for writing the initial config! :heart:
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:
https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227
CDB commands and command line reference:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
regressions, like those fixed in #60687.
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:
https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/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.
|
|
Update RLS
Includes a fix (https://github.com/rust-lang/rls/pull/1462) for breakage due to Cargo update PR (https://github.com/rust-lang/rust/pull/60874)
r? @Manishearth @oli-obk @ehuss
|
|
update Miri
r? @oli-obk
|
|
|
|
|
|
|
|
Use -Zborrowck=mir for NLL compare mode
closes #56993
r? @pnkfelix
|
|
remove compiletest's dependency on `filetime`
|
|
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.
|
|
Rollup of 5 pull requests
Successful merges:
- #60207 (Outdent example, preserving nested fence)
- #60278 (Document the `html_root_url` doc attribute value.)
- #60597 (Do some simple constant propagation in the ConstProp pass)
- #60837 (Update release notes for 1.35.0)
- #60887 (Update clippy)
Failed merges:
r? @ghost
|
|
|
|
|
|
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 https://github.com/rust-lang/rls/blob/5b8e99bb61958ca8abcb7c5eda70521726be1065/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
````
|
|
|
|
|
|
|
|
|
|
Make tests compatible with musl host
As an alternative to passing explicit linker all over the place I could try linking `cc` to musl gcc since this bootstraps itself.
Assigning for discussion:
r? @alexcrichton
|
|
|
