Auto merge of #72978 - matklad:ship-rust-analyzer, r=Mark-Simulacrum
ship rust analyzer
This successfully builds rust-analyzer as a part of rust repo. I haven't yet added required changes to dist.rs -- seems like I just have to copy-paste quite a bit of code I don't really understand :-)
Auto merge of #74019 - Manishearth:rollup-2st3jsk, r=Manishearth
Rollup of 12 pull requests
Successful merges:
- #73140 (Fallback to xml.etree.ElementTree)
- #73670 (Add `format_args_capture` feature)
- #73693 (Use exhaustive match in const_prop.rs)
- #73845 (Use &raw in A|Rc::as_ptr)
- #73861 (Create E0768)
- #73881 (Standardize bibliographic citations in rustc API docs)
- #73925 (Improve comments from #72617, as suggested by RalfJung)
- #73949 ([mir-opt] Fix mis-optimization and other issues with the SimplifyArmIdentity pass)
- #73984 (Edit docs for rustc_data_structures::graph::scc)
- #73985 (Fix "getting started" link)
- #73997 (fix typo)
- #73999 (Bump mingw-check CI image from Ubuntu 16.04 to 18.04.)
Rollup merge of #73999 - eddyb:svv-prereq, r=Mark-Simulacrum
Bump mingw-check CI image from Ubuntu 16.04 to 18.04.
I chose 18.04 because we use it for other builders, and it's enough to get a version of MinGW that can build `libssh2-sys`.
This is a prereq for #73902, where `libssh2-sys` shows up as an indirect dependency of `x.py check src/tools/semverver` (through `src/tools/cargo`, which we don't currently `x.py check` because it's not in-tree). See also https://github.com/rust-lang/rust/pull/73902#issuecomment-652414502.
Rollup merge of #73845 - CAD97:weak-as-unsized-ptr, r=RalfJung
Use &raw in A|Rc::as_ptr
This PR uses `&raw` for offsetting `*mut [A]RcInner<T> -> *mut T`.
Additionally, this updates the implementation of `Weak::as_ptr` to support unsized `T`, though it does not yet relax the bounds of `Weak::as_ptr`/`into_raw`/`from_raw` to accept unsized `T`.
Rollup merge of #73670 - davidhewitt:format-args-capture, r=varkor
Add `format_args_capture` feature
This is the initial implementation PR for [RFC 2795](https://github.com/rust-lang/rfcs/pull/2795).
Note that, as dicussed in the tracking issue (#67984), the feature gate has been called `format_args_capture`.
Next up I guess I need to add documentation for this feature. I've not written any docs before for rustc / std so I would appreciate suggestions on where I should add docs.
Auto merge of #73650 - pietroalbini:ci-aarch64-gnu, r=Mark-Simulacrum
Add Docker image to run AArch64 Linux tests
This PR adds a Docker image to run the AArch64 Linux test suite on a native AArch64 host platform, which will be used in the future to run the test suite in our CI. The image will also be useful for ARM folks to ensure internally that the bugfixes they submit work.
This will be the first Docker image designed to run on a non-x86_64 host platform, and to prevent surprising behavior this PR moves all images requiring a x86_64 host in the `src/ci/docker/host-x86_64` directory. Paths and scripts are changed accordingly, and a helpful error message is added when someone tries to run an image on the wrong architecture:
```
Invalid image: aarch64-gnu
Note: the image exists for the aarch64 host architecture
Note: the current host architecture is x86_64
```
The old emulated and disabled `aarch64-gnu` builder is also removed in this PR.
This PR is best reviewed commit-by-commit.
r? @Mark-Simulacrum
Aleksey Kladov [Thu, 4 Jun 2020 11:11:15 +0000 (13:11 +0200)]
Add rust-analyzer submodule
The current plan is that submodule tracks the `release` branch of
rust-analyzer, which is updated once a week.
rust-analyzer is a workspace (with a virtual manifest), the actual
binary is provide by `crates/rust-analyzer` package.
Note that we intentionally don't add rust-analyzer to `Kind::Test`,
for two reasons.
*First*, at the moment rust-analyzer's test suite does a couple of
things which might not work in the context of rust repository. For
example, it shells out directly to `rustup` and `rustfmt`. So, making
this work requires non-trivial efforts.
*Second*, it seems unlikely that running tests in rust-lang/rust repo
would provide any additional guarantees. rust-analyzer builds with
stable and does not depend on the specifics of the compiler, so
changes to compiler can't break ra, unless they break stability
guarantee. Additionally, rust-analyzer itself is gated on bors, so we
are pretty confident that test suite passes.
Pietro Albini [Fri, 5 Jun 2020 10:36:09 +0000 (12:36 +0200)]
ci: include the architecture in the docker cache key
We're starting to include native aarch64 machines in our CI, but before
this commit the architecture wasn't included in the cache key for our
Docker images. This means there could be conflicts between images
produced on different architectures, hurting our CI times.
This commit fixes the problem by including the output of `uname -m` in
the cache key.
Pietro Albini [Tue, 23 Jun 2020 09:50:48 +0000 (11:50 +0200)]
ci: move all x86_64 runners to the host-x86_64 directory
We need to add runners designed for an aarch64 host system, and it'd be
nice to return an error message if someone tries to run an image
designed for an host architecture in another one.
To start the work on this, this commit moves all the existing builders
in the host-x86_64 directory, and changes the run.sh script to look up
the image in the correct directory based on the host architecture.
Auto merge of #73897 - ehuss:update-cargo, r=ehuss
Update cargo, rls
## cargo
14 commits in c26576f9adddd254b3dd63aecba176434290a9f6..fede83ccf973457de319ba6fa0e36ead454d2e20
2020-06-23 16:21:21 +0000 to 2020-07-02 21:51:34 +0000
- Fix overflow error on 32-bit. (rust-lang/cargo#8446)
- Exclude the target directory from backups using CACHEDIR.TAG (rust-lang/cargo#8378)
- CONTRIBUTING.md: Link to Zulip rather than Discord (rust-lang/cargo#8436)
- Update built-in help for features (rust-lang/cargo#8433)
- Update core-foundation requirement from 0.7.0 to 0.9.0 (rust-lang/cargo#8432)
- Parse `# env-dep` directives in dep-info files (rust-lang/cargo#8421)
- Move string interning to util (rust-lang/cargo#8419)
- Expose built cdylib artifacts in the Compilation structure (rust-lang/cargo#8418)
- Remove unused serde_derive dependency from the crates.io crate (rust-lang/cargo#8416)
- Remove unused remove_dir_all dependency (rust-lang/cargo#8412)
- Improve git error messages a bit (rust-lang/cargo#8409)
- Improve the description of Config.home_path (rust-lang/cargo#8408)
- Improve support for non-`master` main branches (rust-lang/cargo#8364)
- Document that OUT_DIR in JSON messages is an absolute path (rust-lang/cargo#8403)
Auto merge of #73977 - Manishearth:rollup-2x4s7c6, r=Manishearth
Rollup of 8 pull requests
Successful merges:
- #73454 (Move contributing.md to rustc-dev-guide and point at getting started)
- #73724 (Use WASM's saturating casts if they are available)
- #73726 (resolve: disallow labelled breaks/continues through closures/async blocks)
- #73753 (Use 'tcx for references to AccessLevels wherever possible.)
- #73781 (Update psm version)
- #73952 (Add option for local docker testing.)
- #73957 (disable BTree min_max test in Miri for now)
- #73975 (Document rustc_ast::ast::Pat)
Rollup merge of #73952 - ehuss:docker-dev, r=Mark-Simulacrum
Add option for local docker testing.
This adds the option `--dev` to `src/ci/docker/run.sh` so that it will enter an interactive environment for local testing. I have often needed this for testing things, but I always needed to edit this script. I wanted the ability to interact in the environment, run different commands, inspect errors, etc.
Rollup merge of #73726 - davidtwco:issue-73541-labelled-break-through-closure-async, r=petrochenkov
resolve: disallow labelled breaks/continues through closures/async blocks
Fixes #73541.
This PR modifies name resolution to prohibit labelled breaks/continues through closures or async blocks, fixing an ICE. In addition, it improves the diagnostics surrounding labelled breaks/continues through closures or async blocks by informing the user if the label exists in an parent scope and telling them that won't work.
r? @petrochenkov (resolve)
cc @estebank (diagnostic changes) @tmandry (issue is from `wg-async-foundations`)
Rollup merge of #73724 - CryZe:wasm-saturating-casts, r=alexcrichton
Use WASM's saturating casts if they are available
WebAssembly supports saturating floating point to integer casts behind a target feature. The feature is already available on many browsers. Beginning with 1.45 Rust will start defining the behavior of floating point to integer casts to be saturating as well. For this Rust constructs additional checks on top of the `fptoui` / `fptosi` instructions it emits. Here we introduce the possibility for the codegen backend to construct saturating casts itself and only fall back to constructing the checks ourselves if that is not possible.
Auto merge of #73751 - eddyb:no-empty-tables, r=nikomatsakis
Remove `TypeckTables::empty(None)` and make hir_owner non-optional.
Each commit before the last one removes uses of `TypeckTables::empty(None)`, replacing the empty tables with having `Option` around the `&'tcx TypeckTables<'tcx>` that HIR visitors kept track of.
The last commit removes the concept of "empty `TypeckTables`" altogether, guaranteeing that every `TypeckTables` corresponds to a HIR body owner.
David Wood [Thu, 25 Jun 2020 14:16:38 +0000 (15:16 +0100)]
resolve: disallow label use through closure/async
This commit modifies resolve to disallow `break`/`continue` to labels
through closures or async blocks. This doesn't make sense and should
have been prohibited anyway.
Auto merge of #73954 - Manishearth:rollup-8qvh170, r=Manishearth
Rollup of 10 pull requests
Successful merges:
- #73414 (Implement `slice_strip` feature)
- #73564 (linker: Create GNU_EH_FRAME header by default when producing ELFs)
- #73622 (Deny unsafe ops in unsafe fns in libcore)
- #73684 (add spans to injected coverage counters, extract with CoverageData query)
- #73812 (ast_pretty: Pass some token streams and trees by reference)
- #73853 (Add newline to rustc MultiSpan docs)
- #73883 (Compile rustdoc less often.)
- #73885 (Fix wasm32 being broken due to a NodeJS version bump)
- #73903 (Changes required for rustc/cargo to build for iOS targets)
- #73938 (Optimise fast path of checked_ops with `unlikely`)
Christopher Serr [Thu, 25 Jun 2020 15:05:12 +0000 (17:05 +0200)]
Use WASM's saturating casts if they are available
WebAssembly supports saturating floating point to integer casts behind a
target feature. The feature is already available on many browsers.
Beginning with 1.45 Rust will start defining the behavior of floating
point to integer casts to be saturating as well. For this Rust
constructs additional checks on top of the `fptoui` / `fptosi`
instructions it emits. Here we introduce the possibility for the codegen
backend to construct saturating casts itself and only fall back to
constructing the checks ourselves if that is not possible.
Rollup merge of #73885 - pietroalbini:ci-fix-wasm32, r=kennytm
Fix wasm32 being broken due to a NodeJS version bump
Emscripten's SDK [recently bumped the version of NodeJS they shipped](https://github.com/emscripten-core/emsdk/pull/529), but our Dockerfile for the wasm32 builder hardcoded the version number. This will cause consistent CI failures once the currently cached image is rebuilt (either due to a change or due to the cache expiring).
This PR fixes the problem by finding the latest version of NodeJS in the Emscripten SDK and symlinking it to a "latest" directory, which is then added to the `PATH`.
Rollup merge of #73883 - ehuss:rustdoc-stage-previous, r=Mark-Simulacrum
Compile rustdoc less often.
Previously rustdoc was built 3 times with `x.py test`:
1. stage2 (using stage1 compiler) for compiletest tests (stage1-tools copied to stage2).
2. stage1 (using stage0 compiler) for std crate tests (stage0-tools copied to stage1).
3. stage2 test (using stage2 compiler) for rustdoc crate tests and error_index_generator (stage2-tools).
This PR removes the majority of number 3, where it will instead use the stage1 compiler, which will share the artifacts from number 1.
This matches the behavior of the libstd crate tests. I don't think it is entirely necessary to run the tests using stage2.
At `-j2`, the last build step goes from about 300s to 70s on my machine. It's not a huge win, but shaving 4 minutes isn't bad.
The other two builds would be pretty difficult (or undesired or impossible) to unify. It looks like std tests use stage1 very intentionally (see `force_use_stage1` and its history), and compiletests use the top stage very intentionally.
Unfortunately the linkchecker builds all docs at stage2 (stage2-tools), which means a few build script artifacts are not shared. It's not really clear to me how to fix that (because it uses `default_doc`, there doesn't seem to be any control over the stages).
---
For `x.py doc`, rustdoc was previously built three times (with compiler-docs):
1. stage2 (using stage1 compiler) for normal documentation output (stage1-tools copied to stage2).
2. stage1 (using stage0 compiler) for compiler-docs
3. stage2 (using stage2 compiler) for error_index_generator (stage2-tools)
This PR combines these so that they consistently use the "top stage" rustdoc. I don't know why the compiler-docs was written to use stage minus one, but it seems better to be consistent across the doc steps.
---
I've tried to test this with a variety of commands (`x.py doc`, `x.py test`, different `--stage` flags, `full-bootstrap`, setting `--target`, etc.) to try to make sure there aren't significant regressions here. It's tricky since there are so many variables, and this stuff is difficult for me to fully understand.
Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2, r=wesleywiser
add spans to injected coverage counters, extract with CoverageData query
This is the next iteration on the Rust Coverage implementation, and follows PR #73488
@tmandry @wesleywiser
I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query.
I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization).
If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values.
Let me know your thoughts. Thanks!
r? @tmandry
Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
Rollup merge of #73622 - LeSeulArtichaut:unsafe-libcore, r=nikomatsakis
Deny unsafe ops in unsafe fns in libcore
After `liballoc`, It's time for `libcore` :D
I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly.
Rollup merge of #73909 - eltonlaw:unsafe-libstd-fs-rs, r=sfackler
`#[deny(unsafe_op_in_unsafe_fn)]` in libstd/fs.rs
The `libstd/fs.rs` part of https://github.com/rust-lang/rust/issues/73904 . Wraps the two calls to an unsafe fn `Initializer::nop()` in an `unsafe` block.
Followed instructions in parent issue, ran `./x.py check src/libstd/` after adding the lint and two warnings were given. After adding these changes, those disappear.
Rollup merge of #73898 - lcnr:issue61383, r=jonas-schievink
remove duplicate test for #61935
Apparently I somehow messed up the issue number in #67890
which caused us to add this test twice, both as https://github.com/rust-lang/rust/blob/master/src/test/ui/const-generics/issues/issue-61935.rs and https://github.com/rust-lang/rust/blob/master/src/test/ui/const-generics/lazy-normalization/issue-71922.rs
#61935 is the actually fixed issue while #71922 is still not working, as it depends on lazy norm of repeat expressions
Rollup merge of #73839 - crlf0710:snapshot_the_reality, r=Manishearth
Split and expand nonstandard-style lints unicode unit test.
RFC 2457 requested that the `nonstandard_style` series of linted be adjusted to cover the non_ascii_identifier case. However when i read the code of those implementations, it seems they're already supporting non_ascii_identifiers. But the exact rules is a little different than what's proposed in RFC 2457.
So I splitted and expanded the existing test case to try to exercise every branch in the code. I think it'll also be easier to examine the cases in these unit tests to see whether it's ok to just leave them as is, or some adjustments are needed.
Rollup merge of #73803 - Aaron1011:feature/angle-field-recovery, r=matthewjasper
Recover extra trailing angle brackets in struct definition
This commit applies the existing 'extra angle bracket recovery' logic
when parsing fields in struct definitions. This allows us to continue
parsing the struct's fields, avoiding spurious 'missing field' errors in
code that tries to use the struct.
Rollup merge of #73569 - Aaron1011:fix/macro-rules-group, r=petrochenkov
Handle `macro_rules!` tokens consistently across crates
When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition.
This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case.
To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from.
This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group.
See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
Rollup merge of #73449 - ehuss:duplicate-lang-item, r=matthewjasper
Provide more information on duplicate lang item error.
This gives some notes on the location of the files where the lang items were loaded from. Some duplicate lang item errors can be a little confusing, and this might help in diagnosing what has happened.
Here's an example when hitting a bug with Cargo's build-std:
```
error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `try`.
|
= note: the lang item is first defined in crate `core` (which `z10` depends on)
= note: first definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-a764da499c7385f4.rmeta
= note: second definition in `core` loaded from /Users/eric/Proj/rust/cargo/scratch/z10/target/target/debug/deps/libcore-5b082675aea34986.rmeta
```
Rollup merge of #73345 - petrochenkov:nointerp, r=Aaron1011
expand: Stop using nonterminals for passing tokens to attribute and derive macros
Make one more step towards fully token-based expansion and fix issues described in https://github.com/rust-lang/rust/issues/72545#issuecomment-640276791.
Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later.
The cost is making pretty-printing of token streams less pretty.
Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway.
Unfortunately, this is not exactly the same thing as https://github.com/rust-lang/rust/pull/73102.
One more observable effect is how `$crate` is printed in the attribute input.
Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see https://github.com/rust-lang/rust/pull/62393 and related PRs).
This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed.
So, I think we should do this regardless, but we need to run crater first.
r? @Aaron1011
Rollup merge of #72569 - ChrisDenton:remove-innosetup, r=nikomatsakis
Remove legacy InnoSetup GUI installer
On Windows the InnoSetup `.exe` installer was superseded by the MSI installer long ago. It's no longer needed.
The `.exe` installer hasn't been linked from the [other installation methods](https://forge.rust-lang.org/infra/other-installation-methods.html#standalone) page in many years. As far as I can tell the intent was always to remove this installer once the MSI proved itself. Though admittedly both installers feel very "legacy" at this point.
Removing this would mean we only maintain one Windows GUI installer and would speed up the distribution phase.
As a result of removing InnoSetup, this closes #24397
projects / rust.git / log