Commit graph

1436 commits

Author SHA1 Message Date
Matthias Krüger ccfee3d53b
Rollup merge of #92849 - flip1995:clippyup, r=Manishearth
Clippyup

r? ```@Manishearth```
2022-01-14 07:47:37 +01:00
Andy Russell 51d7665be1
rustdoc: remove hand-rolled isatty 2022-01-13 11:13:01 -05:00
flip1995 159d6c356e
Update Cargo.lock 2022-01-13 13:18:51 +01:00
Matthias Krüger a9fe2b95da
Rollup merge of #92807 - ehuss:update-cargo, r=ehuss
Update cargo

6 commits in 358e79fe56fe374649275ca7aebaafd57ade0e8d..06b9d31743210b788b130c8a484c2838afa6fc27
2022-01-04 18:39:45 +0000 to 2022-01-11 23:47:29 +0000
- Port cargo to clap3 (rust-lang/cargo#10265)
- feat: support rustflags per profile (rust-lang/cargo#10217)
- Make bors ignore the PR template so it doesn't end up in merge messages (rust-lang/cargo#10267)
- Be resilient to most IO error and filesystem loop while walking dirs (rust-lang/cargo#10214)
- Remove the option to disable pipelining (rust-lang/cargo#10258)
- Always ask rustc for messages about artifacts, and always process them (rust-lang/cargo#10255)
2022-01-13 08:11:22 +01:00
Matthias Krüger c7ada001ec
Rollup merge of #90001 - Fearyncess:master, r=alexcrichton
Make rlib metadata strip works with MIPSr6 architecture

Because MIPSr6 has many differences with previous MIPSr2 arch, the previous rlib metadata stripping code in `rustc_codegen_ssa` is only for MIPSr2/r3/r5 (which share the same elf e_flags).

This commit fixed this problem. It makes `rustc_codegen_ssa` happy when compiling rustc for MIPSr6 target or hosts.

e_flags REF: e356027016/llvm/include/llvm/BinaryFormat/ELF.h (L562)
2022-01-13 08:11:16 +01:00
Eric Huss 66f1e322c6 Update cargo 2022-01-11 20:18:29 -08:00
Josh Stone f3b8812f24 Update rayon and rustc-rayon 2022-01-10 11:34:07 -08:00
Dirkjan Ochtman 93a16cb7e2 Migrate rustdoc from Tera to Askama
See #84419.
2022-01-10 18:40:54 +01:00
Lain Yang 9a337b6fe0 update Cargo.lock and gimli-rs/object for rustc_codegen_ssa 2022-01-07 13:33:20 +08:00
David Wood 2dc1a8a779 cg: use thorin instead of llvm-dwp
`thorin` is a Rust implementation of a DWARF packaging utility that
supports reading DWARF objects from archive files (i.e. rlibs) and
therefore is better suited for integration into rustc.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-01-06 09:32:42 +00:00
Matthias Krüger a0673468ae
Rollup merge of #92579 - RalfJung:miri, r=RalfJung
update Miri

Fixes https://github.com/rust-lang/rust/issues/92527
2022-01-05 11:26:09 +01:00
Matthias Krüger d83dd85253
Rollup merge of #92545 - dtolnay:rustlog, r=petrochenkov
Extract init_env_logger to crate

I've been doing some work on rustc_ast_pretty using an out-of-tree main.rs and Cargo.toml with the following:

```toml
[dependencies]
rustc_ast = { path = "../rust/compiler/rustc_ast" }
rustc_ast_pretty = { path = "../rust/compiler/rustc_ast_pretty" }
rustc_span = { path = "../rust/compiler/rustc_span" }
```

Rustc_ast_pretty helpfully uses `tracing::debug!` but I found that in order to enable the debug output, my test crate must depend on rustc_driver which is an enormously bigger dependency than what I have been using so far, and slows down iteration time because an enormous dependency tree between rustc_ast and rustc_driver must now be rebuilt after every ast change.

I pulled out the tracing initialization to a new minimal rustc_log crate so that projects depending on the other rustc crates, like rustc_ast_pretty, can access the `debug!` messages in them without building all the rest of rustc.
2022-01-05 11:26:08 +01:00
Ralf Jung e568423815 update Miri 2022-01-05 10:41:22 +01:00
David Tolnay ffbeebbf7a
Make rustc_log doc test runnable 2022-01-03 22:31:56 -08:00
David Tolnay 6152d15e7c
Extract init_env_logger to crate 2022-01-03 16:45:21 -08:00
Krasimir Georgiev a9698e22ec revert #92254 "Bump gsgdt to 0.1.3"
gsgdt 0.1.3 was yanked:
https://github.com/rust-lang/rust/pull/92254#issuecomment-1004269481
2022-01-03 20:25:46 +01:00
bjorn3 ad6f98cd28 Remove the merge dependency 2022-01-01 17:03:24 +01:00
bjorn3 043745cb96 Avoid the merge derive macro in rustbuild
The task of the macro is simple enough that a decl macro is almost ten
times shorter than the original proc macro. The proc macro is 159 lines
while the decl macro is just 18 lines.

This reduces the amount of dependencies of rustbuild from 45 to 37. It
also slight reduces compilation time from 47s to 44s for debug builds.
2022-01-01 16:56:03 +01:00
bjorn3 2fe2728fa9 Remove the lazy_static dependency from rustbuild
Rustbuild already depends on once_cell which in the future can be
replaced with std::lazy::Lazy.
2022-01-01 16:53:47 +01:00
bors ad0d4190fa Auto merge of #92374 - ehuss:update-libssh2-sys, r=Mark-Simulacrum
Update libssh2-sys

Updates libssh2-sys from 0.2.19 to 0.2.23.  This brings in libssh2 1.10 ([RELEASE-NOTES](https://github.com/libssh2/libssh2/blob/libssh2-1.10.0/RELEASE-NOTES)).  One of the major changes is to add support for OpenSSH agent on Windows.

Closes https://github.com/rust-lang/cargo/issues/10237
2022-01-01 05:21:22 +00:00
bors cfa3fe5af3 Auto merge of #90637 - Mark-Simulacrum:liveness-btree, r=lqd
Store liveness in interval sets for region inference

On the 100,000 line test case from https://github.com/rust-lang/rust/issues/90445, this reduces memory usage from 35 GB to 444 MB at peak (based on DHAT results, though with regular malloc), and yields a 9.4x speedup, with wall time going from 14.5 seconds to 1.5s. Performance results show that for the majority of real-world code this has little to no impact, but it's expected to generally scale better for auto-generated functions and other cases which stress this area of the compiler, as results on #90445 illustrate.

There may also be further room for improvement in future PRs making use of this data structures benefits over raw bitsets (which, at some level, are a less perfect fit for representing liveness, which is almost always composed of contiguous ranges, not point locations).

Fixes #90445.
2021-12-31 19:54:10 +00:00
bors 8ed935e92d Auto merge of #92252 - GuillaumeGomez:update-pulldown, r=camelid,xFrednet
Update pulldown-cmark version to 0.9

Fixes https://github.com/rust-lang/rust/issues/92206.

r? `@camelid`
2021-12-31 12:46:38 +00:00
Mark Rousskov 00c55a1bb8 Introduce IntervalSet
This is a compact, fast storage for variable-sized sets, typically consisting of
larger ranges. It is less efficient than a bitset if ranges are both small and
the domain size is small, but will still perform acceptably. With enormous
domain sizes and large ranges, the interval set performs much better, as it can
be much more densely packed in memory than the uncompressed bit set alternative.
2021-12-30 22:33:44 -05:00
Eric Huss 000d336216 Update libssh2-sys 2021-12-28 13:24:03 -08:00
Guillaume Gomez 4e2024c55d Update pulldown-cmark version in clippy 2021-12-28 16:19:23 +01:00
Guillaume Gomez b5898a1137 Update pulldown-cmark version to 0.9 2021-12-28 16:17:22 +01:00
Krasimir Georgiev 9127f497be Bump gsgdt to 0.1.3
No functional changes intended.

The 0.1.2 -> 0.1.3 commit 3e1dcec539
renames `Node::new` to `Node::from_list`.
2021-12-24 13:46:37 +01:00
bors c1d301bb29 Auto merge of #92167 - pierwill:chalk-update, r=jackh726
Update chalk to 0.75.0

- Compute flags in `intern_ty`
- Remove `tracing-serde` from `PERMITTED_DEPENDENCIES`
- Bump `tracing-tree` to 0.2.0
- Bump `tracing-subscriber` to 0.3.3
2021-12-23 08:59:55 +00:00
pierwill 155a4a87af Upgrade tracing-subscriber 2021-12-22 10:47:36 -06:00
pierwill ea25b779eb Update chalk to 0.75.0
- Compute flags in `intern_ty`
- Remove tracing-serde from PERMITTED_DEPENDENCIES
- Disable `tracing-full` feature in `chalk-solve`
- Bump tracing-tree to 0.2.0
2021-12-22 10:07:44 -06:00
Matthias Krüger 7407c4e37d
Rollup merge of #91172 - Ethiraric:ethiraric/fix90979, r=petrochenkov
Warn when a `#[test]`-like built-in attribute macro is present multiple times.

Fixes #90979.
2021-12-16 17:23:07 +01:00
Ayrton c12f7efd01 Bump compiler-builtins to 0.1.66
Adds intrinsics for truncdfsf2 and truncdfsf2vsp on ARM.
2021-12-15 21:00:06 -05:00
Ethiraric 2be94d4301 Add a lint for duplicated attributes. 2021-12-15 23:43:13 +01:00
Matthias Krüger 22fc403757
Rollup merge of #91940 - ehuss:update-cargo, r=ehuss
Update cargo

14 commits in 40dc281755137ee804bc9b3b08e782773b726e44..a359ce16073401f28b84840da85b268aa3d37c88
2021-12-06 21:54:44 +0000 to 2021-12-14 18:40:22 +0000
- Support `term.quiet` configuration (rust-lang/cargo#10152)
- Display alias target on 'cargo help &lt;alias&gt;` (rust-lang/cargo#10193)
- delete --host command and message (rust-lang/cargo#10145)
- Improve I/O error message for fingerprint of build script (rust-lang/cargo#10191)
- Explicitly mark aliases in `cargo list`. (rust-lang/cargo#10177)
- Don't emit "executable" JSON field for non-executables. (rust-lang/cargo#10171)
- Move scrape-examples docs to correct section. (rust-lang/cargo#10166)
- Do not suggest source config if nothing to vendor (rust-lang/cargo#10161)
- Bump versions of local deps. (rust-lang/cargo#10155)
- Bump to 0.60.0, update changelog (rust-lang/cargo#10154)
- Fix some profile documentation. (rust-lang/cargo#10153)
- Document lib before bin. (rust-lang/cargo#10172)
- Sync cargo-the-cli version with rustc. (rust-lang/cargo#10178)
- Remove `-Z future-incompat-report` from message displayed to user (rust-lang/cargo#10185)
2021-12-15 01:28:10 +01:00
Eric Huss d9dd360f59 Update cargo 2021-12-14 15:24:41 -08:00
bors 2f4da6243f Auto merge of #91728 - Amanieu:stable_asm, r=joshtriplett
Stabilize asm! and global_asm!

Tracking issue: #72016

It's been almost 2 years since the original [RFC](https://github.com/rust-lang/rfcs/pull/2850) was posted and we're finally ready to stabilize this feature!

The main changes in this PR are:
- Removing `asm!` and `global_asm!` from the prelude as per the decision in #87228.
- Stabilizing the `asm` and `global_asm` features.
- Removing the unstable book pages for `asm` and `global_asm`. The contents are moved to the [reference](https://github.com/rust-lang/reference/pull/1105) and [rust by example](https://github.com/rust-lang/rust-by-example/pull/1483).
  - All links to these pages have been removed to satisfy the link checker. In a later PR these will be replaced with links to the reference or rust by example.
- Removing the automatic suggestion for using `llvm_asm!` instead of `asm!` if you're still using the old syntax, since it doesn't work anymore with `asm!` no longer being in the prelude. This only affects code that predates the old LLVM-style `asm!` being renamed to `llvm_asm!`.
- Updating `stdarch` and `compiler-builtins`.
- Updating all the tests.

r? `@joshtriplett`
2021-12-14 21:15:22 +00:00
bors 6bda5b331c Auto merge of #90716 - euclio:libloading, r=cjgillot
replace dynamic library module with libloading

This PR deletes the `rustc_metadata::dynamic_lib` module in favor of the popular and better tested [`libloading` crate](https://github.com/nagisa/rust_libloading/).

We don't benefit from `libloading`'s symbol lifetimes since we end up leaking the loaded library in all cases, but the call-sites look much nicer by improving error handling and abstracting away some transmutes. We also can remove `rustc_metadata`'s direct dependencies on `libc` and `winapi`.

This PR also adds an exception for `libloading` (and its license) to tidy, so this will need sign-off from the compiler team.
2021-12-12 17:28:52 +00:00
Amanieu d'Antras 44a3a66ee8 Stabilize asm! and global_asm!
They are also removed from the prelude as per the decision in
https://github.com/rust-lang/rust/issues/87228.

stdarch and compiler-builtins are updated to work with the new, stable
asm! and global_asm! macros.
2021-12-12 11:20:03 +00:00
bors e6b883c74f Auto merge of #91665 - matthiaskrgr:rollup-o3wnkam, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #90709 (Only shown relevant type params in E0283 label)
 - #91551 (Allow for failure of subst_normalize_erasing_regions in const_eval)
 - #91570 (Evaluate inline const pat early and report error if too generic)
 - #91571 (Remove unneeded access to pretty printer's `s` field in favor of deref)
 - #91610 (Link to rustdoc_json_types docs instead of rustdoc-json RFC)
 - #91619 (Update cargo)
 - #91630 (Add missing whitespace before disabled HTML attribute)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-12-08 18:45:03 +00:00
Matthias Krüger 75e2f794dc
Rollup merge of #91619 - ehuss:update-cargo, r=ehuss
Update cargo

8 commits in 294967c53f0c70d598fc54ca189313c86c576ea7..40dc281755137ee804bc9b3b08e782773b726e44
2021-11-29 19:04:22 +0000 to 2021-12-06 21:54:44 +0000
- Unify the description of quiet flag (rust-lang/cargo#10168)
- Stabilize future-incompat-report (rust-lang/cargo#10165)
- Support abbreviating `--release` as `-r` (rust-lang/cargo#10133)
- doc: nudge towards simple version requirements (rust-lang/cargo#10158)
- Upgrade clap to 2.34.0 (rust-lang/cargo#10164)
- Treat EOPNOTSUPP the same as ENOTSUP when ignoring failed flock calls. (rust-lang/cargo#10157)
- Add note about RUSTFLAGS removal from build scripts. (rust-lang/cargo#10141)
- Make clippy happy (rust-lang/cargo#10139)
2021-12-08 16:08:11 +01:00
bors f9e77f2b46 Auto merge of #91604 - nikic:section-flags, r=nagisa
Use object crate for .rustc metadata generation

We already use the object crate for generating uncompressed .rmeta
metadata object files. This switches the generation of compressed
.rustc object files to use the object crate as well. These have
slightly different requirements in that .rmeta should be completely
excluded from any final compilation artifacts, while .rustc should
be part of shared objects, but not loaded into memory.

The primary motivation for this change is #90326: In LLVM 14, the
current way of setting section flags (and in particular, preventing
the setting of SHF_ALLOC) will no longer work. There are other ways
we could work around this, but switching to the object crate seems
like the most elegant, as we already use it for .rmeta, and as it
makes this independent of the codegen backend. In particular, we
don't need separate handling in codegen_llvm and codegen_gcc.
codegen_cranelift should be able to reuse the implementation as
well, though I have omitted that here, as it is not based on
codegen_ssa.

This change mostly extracts the existing code for .rmeta handling
to allow using it for .rustc as well, and adjusts the codegen
infrastructure to handle the metadata object file separately: We
no longer create a backend-specific module for it, and directly
produce the compiled module instead.

This does not `fix` #90326 by itself yet, as .llvmbc will need to be
handled separately.

r? `@nagisa`
2021-12-08 14:58:48 +00:00
bors abba5edf48 Auto merge of #91500 - ehuss:update-mdbook, r=Mark-Simulacrum
Update mdbook

This just includes a few minor fixes:
* https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0413
* https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0414
2021-12-08 04:46:39 +00:00
Nikita Popov 9488cacc52 Use object crate for .rustc metadata generation
We already use the object crate for generating uncompressed .rmeta
metadata object files. This switches the generation of compressed
.rustc object files to use the object crate as well. These have
slightly different requirements in that .rmeta should be completely
excluded from any final compilation artifacts, while .rustc should
be part of shared objects, but not loaded into memory.

The primary motivation for this change is #90326: In LLVM 14, the
current way of setting section flags (and in particular, preventing
the setting of SHF_ALLOC) will no longer work. There are other ways
we could work around this, but switching to the object crate seems
like the most elegant, as we already use it for .rmeta, and as it
makes this independent of the codegen backend. In particular, we
don't need separate handling in codegen_llvm and codegen_gcc.
codegen_cranelift should be able to reuse the implementation as
well, though I have omitted that here, as it is not based on
codegen_ssa.

This change mostly extracts the existing code for .rmeta handling
to allow using it for .rustc as well, and adjust the codegen
infrastructure to handle the metadata object file separately: We
no longer create a backend-specific module for it, and directly
produce the compiled module instead.

This does not fix #90326 by itself yet, as .llvmbc will need to be
handled separately.
2021-12-07 09:39:05 +01:00
Eric Huss 4aceaedb5e Update cargo 2021-12-06 20:33:00 -08:00
Andy Russell 923f939791
replace dynamic library module with libloading 2021-12-06 12:03:47 -05:00
flip1995 e36e5a519b
Update Cargo.lock 2021-12-06 12:33:55 +01:00
Eric Huss a882fdd334 Update mdbook 2021-12-03 12:25:07 -08:00
William D. Jones e500eb6950 Bump compiler_builtins to 0.1.55 to bring in fixes for targets lacking atomic support. 2021-11-28 23:01:03 -05:00
Jubilee Young 9a04ae4997 Update libc to 0.2.108
Changelog:
https://github.com/rust-lang/libc/releases/tag/0.2.107
https://github.com/rust-lang/libc/releases/tag/0.2.108
Primarily intended to pull in fd331f65f214ea75b6210b415b5fd8650be15c73
This should help with https://github.com/rust-lang/rust/pull/90044
2021-11-27 16:13:04 -08:00
Alessandro Decina 1cf37189bc Bump compiler-builtins to 0.1.53
Fixes a LLVM crash with the bpf targets
2021-11-26 10:33:32 +00:00
Esteban Kuber 5a68abb094 Tokenize emoji as if they were valid indentifiers
In the lexer, consider emojis to be valid identifiers and reject
them later to avoid knock down parse errors.
2021-11-23 20:35:07 +00:00
Eric Huss b086bd0412 Update cargo 2021-11-22 14:01:57 -08:00
Alex Crichton e4b3496618 Update stdarch/dlmalloc
Ensure that they compile with the now-a-feature-is-required logic.
2021-11-10 08:35:43 -08:00
Alex Crichton b5c3f4c5d8 Update dlmalloc for libstd
This pulls in a fix for wasm64 to work correctly with this dlmalloc
2021-11-10 08:35:43 -08:00
Alex Crichton 88f1bf73ee Update stdarch/compiler_builtins
Brings in some fixes and better support for the wasm64 target.
2021-11-10 08:35:42 -08:00
Eric Huss 05db283453 Update cargo 2021-11-09 00:22:06 -08:00
flip1995 4e5319b622
Update Cargo.lock 2021-11-04 12:56:54 +00:00
bors 0b4ac62dda Auto merge of #90392 - solid-rs:fix-solid-support, r=Mark-Simulacrum
kmc-solid: Fix SOLID target

This PR is a follow-up for #86191 and necessary to make the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets actually usable.

 - Bumps `libc` to 0.2.106, which includes <https://github.com/rust-lang/libc/pull/2227>.
 - Applies the change made by #89324 to this target's target-specific code.
2021-11-04 03:48:43 +00:00
Matthias Krüger 673aafe70e
Rollup merge of #90500 - xFrednet:00000-update-clippy-deps, r=flip1995
Update Clippy dependencies

Clippy has two outdated dependencies, where one indirect dependency has been flagged by rustsec for dropping a lifetime. See [RUSTSEC-2020-0146](https://rustsec.org/advisories/RUSTSEC-2020-0146). This PR updates these dependencies.

With previous dependency updates, it was tried to prevent duplicates in the `Cargo.lock` file of rust-lang/rust. I've tried to keep this in mind with this update.

* Dependency `semver`
    * Used in `src/tools/cargo/Cargo.toml` as version `1.0.3`
    * Used in `src/tools/rust-analyzer/crates/project_model/Cargo.toml` as version `1`
    * Updated in Clippy from `0.11` to `1.0` (Clippy usually defines the major and minor patch version). The `Cargo.lock` file lists `1.0.3` which is one patch version behind the most recent one but prevents a duplicate with cargo's pinned version.
* Dependency `cargo_metadata`
    * Used in several tools as `0.14`
    * Used in `src/tools/tidy` and `src/tools/rls` as `0.12`
    * Updated in Clippy from `0.12` to `0.14`

All updates to the `Cargo.lock` have been done automatically by `x.py`.

There are still some tools with these outdated dependencies. Clippy didn't require any changes, and it would be likely that the others could also be updated without any problem. Let me know if I should try to update them as well 🙃.

Keep up the good work, whoever is reading this 🦀

---

For Clippy:

changelog: none
2021-11-02 23:48:49 +01:00
xFrednet fd41336c4c Update clippy dependencies
* semver = "0.11" -> "1.0"
* cargo_metadata = "0.12" -> "0.14"
2021-11-02 14:19:31 +01:00
Tomoaki Kawada 15af06795c Bump libc dependency of std to 0.2.106 2021-11-01 10:45:49 +09:00
Esteban Küber c0b134582a
Lint against RTL unicode codepoints in literals and comments
Address CVE-2021-42574.
2021-10-31 13:14:04 +01:00
bors 021947d37a Auto merge of #90403 - michaelwoerister:odht-0.3.1, r=Mark-Simulacrum
Update odht crate to 0.3.1 (big-endian bugfix)

Update `odht` to 0.3.1 in order to get https://github.com/rust-lang/odht/pull/20 which fixes issue https://github.com/rust-lang/rust/issues/90123.
2021-10-30 01:01:19 +00:00
Michael Woerister 6771ac3f19 Update odht crate to 0.3.1 (big-endian bugfix) 2021-10-29 18:05:15 +02:00
Noah Lev 7865a85eb6 rustdoc: Switch to mainline rayon
The rustc fork of rayon integrates with Cargo's jobserver to limit the
amount of parallelism. However, rustdoc's use case is concurrent I/O,
which is not CPU-heavy, so it should be able to use mainline rayon.

See this discussion [1] for more details.

[1]: https://github.com/rust-lang/rust/issues/90227#issuecomment-952468618

Note: I chose rayon 1.3.1 so that the rayon version used elsewhere in
the workspace does not change.
2021-10-28 18:26:57 -07:00
Eric Huss 5001cd04a8 Update cargo 2021-10-25 20:30:21 -07:00
Matthias Krüger c400feeb84
Rollup merge of #90087 - calebcartwright:rustfmt-subtree, r=calebcartwright
Sync rustfmt subtree

There's a large number of small fixes and new features, but nothing too big. Detailed changelog for those interested can be found in https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#1438-2021-10-20
2021-10-23 05:28:25 +02:00
flip1995 8d5f69de3b
Update Cargo.lock 2021-10-21 13:13:17 +02:00
Camille GILLOT 602d3cbce3 Invoke callbacks from rustc_middle. 2021-10-20 18:29:33 +02:00
Caleb Cartwright 0697f565f1 update rustfmt 2021-10-20 00:15:20 -05:00
Yuki Okushi 3d95330230
Rollup merge of #87404 - rylev:artifact-size-profiling, r=wesleywiser
Add support for artifact size profiling

This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with).

Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request.

This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency.

This was worked on together with `@michaelwoerister.`

r? `@wesleywiser`
2021-10-20 04:35:11 +09:00
bors 1af55d19c7 Auto merge of #89933 - est31:let_else, r=michaelwoerister
Adopt let_else across the compiler

This performs a substitution of code following the pattern:

```
let <id> = if let <pat> = ... { identity } else { ... : ! };
```

To simplify it to:

```
let <pat> = ... { identity } else { ... : ! };
```

By adopting the `let_else` feature (cc #87335).

The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet.

Note: Generally I'm the person who *removes* usages of unstable features from the compiler, not adds more usages of them, but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.
2021-10-19 14:41:39 +00:00
bors bd41e09da3 Auto merge of #89124 - cjgillot:owner-info, r=michaelwoerister
Index and hash HIR as part of lowering

Part of https://github.com/rust-lang/rust/pull/88186
~Based on https://github.com/rust-lang/rust/pull/88880 (see merge commit).~

Once HIR is lowered, it is later indexed by the `index_hir` query and hashed for `crate_hash`. This PR moves those post-processing steps to lowering itself. As a side objective, the HIR crate data structure is refactored as an `IndexVec<LocalDefId, Option<OwnerInfo<'hir>>>` where `OwnerInfo` stores all the relevant information for an HIR owner.

r? `@michaelwoerister`
cc `@petrochenkov`
2021-10-18 19:53:05 +00:00
est31 ef018be5c4 Update the syn crate and adopt let_else in three more places
The syn crate has gained support for let_else syntax in version 1.0.76,
see https://github.com/dtolnay/syn/pull/1057 .

In the three instances that use let_else, we've sent code through an
attr macro, which would create compile errors when there was no
let_else support in syn. To avoid this, we ran
`cargo +nightly update -p syn` for updating the syn crate.
2021-10-16 07:18:15 +02:00
Cameron Steffen 64d18d4c51 Remove unused dependencies from rustc_const_eval 2021-10-14 15:42:42 -05:00
Eric Huss 9401547cea Update cargo 2021-10-11 21:48:27 -07:00
Camille GILLOT 457de08487 Forbid hashing HIR outside of indexing. 2021-10-09 18:38:28 +02:00
Camille GILLOT 48a339ddbb Store lowering outputs per owner. 2021-10-09 11:56:29 +02:00
Jubilee 1c1c6eda94
Rollup merge of #89288 - rusticstuff:lld_wrapper, r=Mark-Simulacrum
Wrapper for `-Z gcc-ld=lld` to invoke rust-lld with the correct flavor

This PR adds an `lld-wrapper` tool which is installed as `ld` and `ld64` in `lib\rustlib\<host_target>\bin\gcc-ld` directory and whose sole purpose is to invoke `rust-lld` in the parent directory with the correct flavor. Lld decides which flavor to use from either the first two commandline arguments or from the name of the executable (`ld` for GNU/ld flavor, `ld64` for Darwin/Macos/ld64 flavor and so on). Symbolic links could not be used as they are not supported by rustup and on Windows.

The wrapper replaces full copies of rust-lld which added some significant bloat. On UNIXish operating systems it exec rust-lld, on Windows it spawns it as a child process.

Fixes #88869.

r? ```@Mark-Simulacrum```
cc ```@nagisa``` ```@petrochenkov``` ```@1000teslas```
2021-10-07 20:26:13 -07:00
Hans Kratz 6162fc0c80 Add wrapper for -Z gcc-ld=lld to invoke rust-lld with the correct flavor
The wrapper is installed as `ld` and `ld64` in the `lib\rustlib\<host_target>\bin\gcc-ld`
directory and its sole purpose is to invoke `rust-lld` in the parent directory with
the correct flavor.
2021-10-07 16:59:13 +02:00
Guillaume Gomez ab276b82b0
Rollup merge of #89461 - crlf0710:dyn_upcasting_lint, r=nikomatsakis
Add `deref_into_dyn_supertrait` lint.

Initial implementation of #89460. Resolves #89190.
Maybe also worth a beta backport if necessary.

r? `@nikomatsakis`
2021-10-07 16:24:49 +02:00
Ryan Levick 757f76ef73 Update to measureme v10 2021-10-07 15:08:44 +02:00
Ryan Levick 947a33bf20 Add support for artifact size profiling 2021-10-07 14:22:29 +02:00
Manish Goregaokar 79a1fc8419
Rollup merge of #89531 - devnexen:stack_overflow_bsd_libc_upd, r=dtolnay
library std, libc dependency update

to solve #87528 build.
2021-10-06 12:33:22 -07:00
bors 25ec827385 Auto merge of #89363 - oli-obk:in_tracing_we_trust, r=Mark-Simulacrum
Fix performance regression with #[instrument]

linked tracing PR: https://github.com/tokio-rs/tracing/pull/1600

regression introduced by #89048
2021-10-05 12:52:43 +00:00
bors 55111d656f Auto merge of #89266 - cjgillot:session-ich, r=michaelwoerister
Move ICH to rustc_query_system

Based on https://github.com/rust-lang/rust/pull/89183

The StableHashingContext does not need to be in rustc_middle.

This PR moves it to rustc_query_system. This will avoid a dependency between rustc_ast_lowering and rustc_middle in https://github.com/rust-lang/rust/pull/89124.
2021-10-05 09:45:11 +00:00
David Carlier c79447e708 library std, libc dependency update
to solve #87528 build.
2021-10-05 05:58:09 +01:00
Ralf Jung e5d01785f8 update Miri 2021-10-04 18:13:00 -04:00
Camille GILLOT 02025d86ac Remove re-export. 2021-10-03 16:08:54 +02:00
Camille GILLOT c355b2e5cd Move ICH to rustc_query_system. 2021-10-03 16:08:53 +02:00
Camille GILLOT 8961616e60 Move rustc_middle::middle::cstore to rustc_session. 2021-10-03 16:08:51 +02:00
Charles Lew 250d1260e6 Add deref_into_dyn_supertrait lint. 2021-10-03 12:36:40 +08:00
Oli Scherer 69274aa549 Bump tracing to get the instrumentation perf improvement 2021-10-02 08:22:03 +00:00
Manish Goregaokar 37df2753fc
Rollup merge of #87868 - Kixiron:packing-on-the-pounds, r=eddyb
Added -Z randomize-layout flag

An implementation of #77316, it currently randomly shuffles the fields of `repr(rust)` types based on their `DefPathHash`
r? ``@eddyb``
2021-10-01 09:18:16 -07:00
Chase Wilson 09f1542418
Implemented -Z randomize-layout 2021-09-30 14:50:06 -05:00
Camille GILLOT b244b98e7c Move EncodedMetadata to rustc_metadata. 2021-09-30 19:41:32 +02:00
Eric Huss 72556f3b17 Update cargo 2021-09-22 15:06:52 -07:00
Michael Woerister 543a73d678 Update odht crate to 0.3.0
This version of odht contains a potential fix for #89085.
2021-09-20 15:57:45 +02:00
Eric Huss ec64a7a3b6 Update cargo 2021-09-18 13:58:26 -07:00
bors d6cd2c6c87 Auto merge of #82183 - michaelwoerister:lazier-defpathhash-loading2, r=wesleywiser
Simplify lazy DefPathHash decoding by using an on-disk hash table.

This PR simplifies the logic around mapping `DefPathHash` values encountered during incremental compilation to valid `DefId`s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly, i.e. without deserializing the entire table.

The main simplification comes from not having to keep track of `DefPathHashes` being used during the compilation session.
2021-09-18 14:37:39 +00:00
bors 9dd4ce80fb Auto merge of #88956 - ehuss:update-cargo, r=ehuss
Update cargo

13 commits in e515c3277bf0681bfc79a9e763861bfe26bb05db..33ee5f82edb50af87b952c5b28de0f5fb41ebf18
2021-09-08 14:32:15 +0000 to 2021-09-17 13:51:54 +0000
- Update curl-sys (rust-lang/cargo#9917)
- Bump Cargo's curl requirement to 7.79.0 (rust-lang/cargo#9914)
- Revert "When a dependency does not have a version, git or path, fails directly" (rust-lang/cargo#9911)
- Add some contributor docs for debugging testsuite tests. (rust-lang/cargo#9904)
- Fix warnings when documenting with `--document-private-items` (rust-lang/cargo#9903)
- Improve "wrong output" error. (rust-lang/cargo#9905)
- Fix warnings from better precision of `dead_code` lint (rust-lang/cargo#9906)
- Bump to 0.58.0, update changelog (rust-lang/cargo#9900)
- Fix rustc --profile=dev unstable check. (rust-lang/cargo#9898)
- config.md: fix typo (rust-lang/cargo#9896)
- Enable some tests on windows. (rust-lang/cargo#9893)
- Enable strip test on macos. (rust-lang/cargo#9889)
- Fix `cargo fix --edition` on stable. (rust-lang/cargo#9890)
2021-09-17 18:48:26 +00:00
Eric Huss 1626feebf2 Update cargo 2021-09-17 10:55:59 -07:00
Michael Woerister 4d151d92de Update odht to 0.2.1 2021-09-17 15:57:57 +02:00
bors 2c7bc5e33c Auto merge of #87867 - bjorn3:unique_type_id_interner, r=wesleywiser
Use a separate interner type for UniqueTypeId

Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols
with the global interner. In fact the Debug implementation of
UniqueTypeId did exactly this.

Using a separate interner type also avoids prefilling the interner with
unused symbols and allow for optimizing the symbol interner for parallel
access without negatively affecting the single threaded module codegen.
2021-09-15 12:34:31 +00:00
Michael Woerister d0be27c8ec Use on-disk-hash-table format for DefPathHashMap in hir::definitions. 2021-09-14 13:54:41 +02:00
bjorn3 8c7840e8cb Use a separate interner type for UniqueTypeId
Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols
with the global interner. In fact the Debug implementation of
UniqueTypeId did exactly this.

Using a separate interner type also avoids prefilling the interner with
unused symbols and allow for optimizing the symbol interner for parallel
access without negatively affecting the single threaded module codegen.
2021-09-13 14:42:06 +02:00
Samuel E. Moelius III bd4b17a532 Update lockfile 2021-09-09 07:47:22 -04:00
bors 626649ff1f Auto merge of #88615 - flip1995:clippyup, r=Manishearth
Update Clippy

r? `@Manishearth`
2021-09-08 23:52:31 +00:00
bors 97032a6dfa Auto merge of #80522 - cjgillot:borrowcrate, r=oli-obk
Split rustc_mir

The `rustc_mir` crate is the second largest in the compiler.
This PR splits it up into 5 crates:
- rustc_borrowck;
- rustc_const_eval;
- rustc_mir_dataflow;
- rustc_mir_transform;
- rustc_monomorphize.
2021-09-08 20:42:42 +00:00
flip1995 fe247b4df7
Update Cargo.lock 2021-09-08 16:32:16 +02:00
Camille GILLOT c5fc2609f0 Rename rustc_mir to rustc_const_eval. 2021-09-07 20:46:26 +02:00
Camille GILLOT fd9c04fe32 Move the dataflow framework to its own crate. 2021-09-07 19:57:07 +02:00
Camille GILLOT 81a600b6b7 Move monomorphize code to its own crate. 2021-09-07 19:53:04 +02:00
Camille GILLOT bba4be681d Move rustc_mir::transform to rustc_mir_transform. 2021-09-07 00:43:14 +02:00
Camille GILLOT 31a61ccc38 Move rustc_mir::borrow_check to new crate rustc_borrowck. 2021-09-07 00:29:22 +02:00
bors 1698e3cac5 Auto merge of #88692 - hyd-dev:miri, r=RalfJung
Update Miri

Fixes #88671.

r? `@RalfJung`
2021-09-06 21:06:22 +00:00
hyd-dev e671c356bf
Update Cargo.lock 2021-09-07 00:43:27 +08:00
bors 8ceea01bb4 Auto merge of #88362 - pietroalbini:bump-stage0, r=Mark-Simulacrum
Pin bootstrap checksums and add a tool to update it automatically

⚠️ ⚠️ This is just a proactive hardening we're performing on the build system, and it's not prompted by any known compromise. If you're aware of security issues being exploited please [check out our responsible disclosure page](https://www.rust-lang.org/policies/security). ⚠️ ⚠️

---

This PR aims to improve Rust's supply chain security by pinning the checksums of the bootstrap compiler downloaded by `x.py`, preventing a compromised `static.rust-lang.org` from affecting building the compiler. The checksums are stored in `src/stage0.json`, which replaces `src/stage0.txt`. This PR also adds a tool to automatically update the bootstrap compiler.

The changes in this PR were originally discussed in [Zulip](https://zulip-archive.rust-lang.org/stream/241545-t-release/topic/pinning.20stage0.20hashes.html).

## Potential attack

Before this PR, an attacker who wanted to compromise the bootstrap compiler would "just" need to:

1. Gain write access to `static.rust-lang.org`, either by compromising DNS or the underlying storage.
2. Upload compromised binaries and corresponding `.sha256` files to `static.rust-lang.org`.

There is no signature verification in `x.py` as we don't want the build system to depend on GPG. Also, since the checksums were not pinned inside the repository, they were downloaded from `static.rust-lang.org` too: this only protected from accidental changes in `static.rust-lang.org` that didn't change the `*.sha256` files. The attack would allow the attacker to compromise past and future invocations of `x.py`.

## Mitigations introduced in this PR

This PR adds pinned checksums for all the bootstrap components in `src/stage0.json` instead of downloading the checksums from `static.rust-lang.org`. This changes the attack scenario to:

1. Gain write access to `static.rust-lang.org`, either by compromising DNS or the underlying storage.
2. Upload compromised binaries to `static.rust-lang.org`.
3. Land a (reviewed) change in the `rust-lang/rust` repository changing the pinned hashes.

Even with a successful attack, existing clones of the Rust repository won't be affected, and once the attack is detected reverting the pinned hashes changes should be enough to be protected from the attack. This also enables further mitigations to be implemented in following PRs, such as verifying signatures when pinning new checksums (removing the trust on first use aspect of this PR) and adding a check in CI making sure a PR updating the checksum has not been tampered with (see the future improvements section).

## Additional changes

There are additional changes implemented in this PR to enable the mitigation:

* The `src/stage0.txt` file has been replaced with `src/stage0.json`. The reasoning for the change is that there is existing tooling to read and manipulate JSON files compared to the custom format we were using before, and the slight challenge of manually editing JSON files (no comments, no trailing commas) are not a problem thanks to the new `bump-stage0`.

* A new tool has been added to the repository, `bump-stage0`. When invoked, the tool automatically calculates which release should be used as the bootstrap compiler given the current version and channel, gathers all the relevant checksums and updates `src/stage0.json`. The tool can be invoked by running:

  ```
  ./x.py run src/tools/bump-stage0
  ```

* Support for downloading releases from `https://dev-static.rust-lang.org` has been removed, as it's not possible to verify checksums there (it's customary to replace existing artifacts there if a rebuild is warranted). This will require a change to the release process to avoid bumping the bootstrap compiler on beta before the stable release.

## Future improvements

* Add signature verification as part of `bump-stage0`, which would require the attacker to also obtain the release signing keys in order to successfully compromise the bootstrap compiler. This would be fine to add now, as the burden of installing the tool to verify signatures would only be placed on whoever updates the bootstrap compiler, instead of everyone compiling Rust.

* Add a check on CI that ensures the checksums in `src/stage0.json` are the expected ones. If a PR changes the stage0 file CI should also run the `bump-stage0` tool and fail if the output in CI doesn't match the committed file. This prevents the PR author from tweaking the output of the tool manually, which would otherwise be close to impossible for a human to detect.

* Automate creating the PRs bumping the bootstrap compiler, by setting up a scheduled job in GitHub Actions that runs the tool and opens a PR.

* Investigate whether a similar mitigation can be done for "download from CI" components like the prebuilt LLVM.

r? `@Mark-Simulacrum`
2021-09-06 16:01:17 +00:00
bors b27ccbc7e1 Auto merge of #87114 - cjgillot:abilint, r=estebank
Lint missing Abi in ast validation instead of lowering.
2021-09-02 06:06:24 +00:00
bors 29ef6cf163 Auto merge of #88506 - Mark-Simulacrum:fix-rlibs, r=ehuss
Fix loading large rlibs

Bumps object crate to permit parsing archives with 64-bit table entries. These
are primarily encountered when there's more than 4GB of archive data.

cc https://github.com/gimli-rs/object/issues/365

Helps with https://github.com/rust-lang/rust/issues/88351, but will also need a beta backport

r? `@ehuss` (mostly for the test)
2021-08-31 19:33:06 +00:00
Camille GILLOT 8d7d488d3b Lint Abi in ast validation. 2021-08-31 20:30:17 +02:00
Mara Bos caca256b52
Rollup merge of #88503 - m-ou-se:array-into-inter-ambiguous, r=cjgillot
Warn when [T; N].into_iter() is ambiguous in the new edition.

Fixes https://github.com/rust-lang/rust/issues/88475

In https://github.com/rust-lang/rust/issues/88475, a situation was found where `[T; N].into_iter()` becomes *ambiguous* in the new edition. This is different than the case where `(&[T; N]).into_iter()` resolves differently, which was the only case handled by the `array_into_iter` lint. This is almost identical to the new-traits-in-the-prelude problem. Effectively, due to the array-into-iter hack disappearing in Rust 2021, we effectively added `IntoIterator` to the 'prelude' in Rust 2021 specifically for arrays.

This modifies the prelude collisions lint to detect that case and emit a `array_into_iter` lint in that case.
2021-08-31 10:41:29 +02:00
Mark Rousskov 4c7c97a208 Fix loading large rlibs
Bumps object crate to permit parsing archives with 64-bit table entries. These
are primarily encountered when there's more than 4GB of archive data.
2021-08-30 16:22:53 -04:00
Mara Bos 336f31432d Warn when [T; N].into_iter() is ambiguous in the new edition. 2021-08-30 21:27:31 +02:00
bors 6cfa773583 Auto merge of #87680 - mati865:stacker-psm-update, r=Mark-Simulacrum,nagisa
Update stacker and psm crates

Primarily to include https://github.com/rust-lang/stacker/pull/54
2021-08-30 10:42:53 +00:00
Guillaume Gomez efed604c26
Rollup merge of #88396 - klensy:bump-deps-vuln, r=Mark-Simulacrum
Bump vulnerable crates

crossbeam-deque v0.7.3 -> v0.7.4:
    https://rustsec.org/advisories/RUSTSEC-2021-0093
    https://github.com/crossbeam-rs/crossbeam/pull/728/files

openssl-src v111.15.0+1.1.1k -> v111.16.0+1.1.1l:
    https://rustsec.org/advisories/RUSTSEC-2021-0097
    https://rustsec.org/advisories/RUSTSEC-2021-0098
    https://www.openssl.org/news/vulnerabilities-1.1.1.html

tar v0.4.35 -> v0.4.37:
    https://rustsec.org/advisories/RUSTSEC-2021-0080
    updated to 0.4.37 as there breaking change in 0.4.36: https://github.com/alexcrichton/tar-rs/pull/260
2021-08-29 16:25:33 +02:00
inquisitivecrystal 8c62fa0575 Treat macros as HIR items 2021-08-28 00:16:34 -07:00
Mateusz Mikuła f58289cc51 Update stacker and psm crates 2021-08-28 00:40:49 +02:00
klensy 92e30f608b crossbeam-deque v0.7.3 -> v0.7.4:
https://rustsec.org/advisories/RUSTSEC-2021-0093
    https://github.com/crossbeam-rs/crossbeam/pull/728/files

openssl-src v111.15.0+1.1.1k -> v111.16.0+1.1.1l:
    https://rustsec.org/advisories/RUSTSEC-2021-0097
    https://rustsec.org/advisories/RUSTSEC-2021-0098
    https://www.openssl.org/news/vulnerabilities-1.1.1.html

tar v0.4.35 -> v0.4.37:
    https://rustsec.org/advisories/RUSTSEC-2021-0080
    updated to 0.4.37 as there breaking change in 0.4.36: https://github.com/alexcrichton/tar-rs/pull/260
2021-08-27 17:38:53 +03:00
Eric Huss 167ee54904 Update cargo 2021-08-26 20:04:45 -07:00
Pietro Albini ea8b1ffe61
pin the stage0 hashes in src/stage0.json 2021-08-26 15:29:30 +02:00
Pietro Albini 80b81adc63
switch stage0.txt to stage0.json and add a tool to generate it 2021-08-26 15:29:27 +02:00
Eduard-Mihai Burtescu f8810ee171 Update rustc-demangle to 0.1.21. 2021-08-24 19:53:20 +03:00
Aaron Hill af46699f81
Remove Session.used_attrs and move logic to CheckAttrVisitor
Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).

`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`

Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.

We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.

With this commit, a large source of global untracked state is removed.
2021-08-21 13:27:27 -05:00
bors 7960030d69 Auto merge of #88151 - alexcrichton:update-backtrace, r=Mark-Simulacrum
Update the backtrace crate in libstd

This commit updates the backtrace crate in libstd now that dependencies
have been updated to use `memchr` from the standard library as well.
This is mostly just making sure deps are up-to-date and have all the
latest-and-greatest fixes and such.

Closes rust-lang/backtrace-rs#432
2021-08-19 17:20:59 +00:00
Alex Crichton 4a3e73643a Update the backtrace crate in libstd
This commit updates the backtrace crate in libstd now that dependencies
have been updated to use `memchr` from the standard library as well.
This is mostly just making sure deps are up-to-date and have all the
latest-and-greatest fixes and such.

Closes rust-lang/backtrace-rs#432
2021-08-19 07:31:49 -07:00
bors a9ab2e5539 Auto merge of #88002 - hermitcore:unbox-mutex, r=dtolnay
Unbox mutexes, condvars and rwlocks on hermit

[RustyHermit](https://github.com/hermitcore/rusty-hermit) provides now movable synchronization primitives and we are able to unbox mutexes and condvars.
2021-08-19 09:08:11 +00:00
bors 3d0774d0dc Auto merge of #86700 - lqd:matthews-nll-hrtb-errors, r=nikomatsakis
Matthew's work on improving NLL's "higher-ranked subtype error"s

This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374.

These are a blocker to turning full NLLs on, and doing some internal cleanups to remove some of the old region code.

The goal is so `@nikomatsakis` can take a look at this early, and I'll then do my best to help do the changes and followup work to land this work, and move closer to turning off the migration mode.

I've only updated the branch and made it compile, removed a warning or two.

r? `@nikomatsakis`

(Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)
2021-08-18 15:54:59 +00:00
bors 29d61427ac Auto merge of #88127 - ehuss:update-cargo, r=ehuss
Update cargo

8 commits in b51439fd8b505d4800a257acfecf3c69f81e35cf..e96bdb0c3d0a418e7fcd7fbd69be08abf830b4bc
2021-08-09 18:40:05 +0000 to 2021-08-17 22:58:47 +0000
- Support using rustbot to ping the Windows group (rust-lang/cargo#9802)
- Show information about abnormal `fix` errors. (rust-lang/cargo#9799)
- Bump jobserver. (rust-lang/cargo#9798)
- Render build-std web links as hyperlinks (rust-lang/cargo#9795)
- Teach cargo to failfast on recursive/corecursive aliases (rust-lang/cargo#9791)
- Fix value-after-table error with profiles. (rust-lang/cargo#9789)
- Fix plugin registrar change. (rust-lang/cargo#9790)
- Ability to specify the output name for a bin target different from the crate name (rust-lang/cargo#9627)
2021-08-18 13:24:17 +00:00
bors 679dea4cc3 Auto merge of #87738 - lqd:polonius-master, r=nikomatsakis
Update `polonius-engine` to 0.13.0

This PR updates the use of `polonius-engine` to the recently released 0.13.0:
- this version renamed a lot of relations to match the current terminology
- "illegal subset relationships errors" (AKA "subset errors" or "universal region errors" in rustc parlance) have been implemented in all variants, and therefore the `Hybrid` variant can be the rustc default once again
- some of the blessed expectations were updated: new tests have been added since the last time I updated the tests, diagnostics have changed, etc.

In particular:
- a few tests had trivial expectations changes such as basic diagnostics changes for the migrate-mode and full NLLs
- others were recursion and lengths limits which emits a file, and under the polonius compare-mode, the folder has a different name
- a few tests were ignored in the NLL compare-mode for reasons that obviously also apply to Polonius
- some diagnostics were unified so that older expectations no longer made sense: the NLL and Polonius outputs were identical.
- in a few cases Polonius gets a chance to emit more errors than NLLs

A few tests in the compare-mode still are super slow and trigger the 60s warning, or OOM rustc during fact generation, and I've detailed these [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/186049-t-compiler.2Fwg-polonius/topic/Challenges.20for.20move.2Finit.2C.20liveness.2C.20and.20.60Location.3A.3AAll.60):
- `src/test/ui/numbers-arithmetic/saturating-float-casts.rs` -> OOM during rustc fact generation
- `src/test/ui/numbers-arithmetic/num-wrapping.rs`
- `src/test/ui/issues/issue-72933-match-stack-overflow.rs`
- `src/test/ui/issues/issue-74564-if-expr-stack-overflow.rs`
- `src/test/ui/repr/repr-no-niche.rs`

In addition, 2 tests don't currently pass and I didn't want to bless them now: they deal with HRTBs and miss errors that NLLs emit. We're currently trying to see if we need chalk to deal with HRTB errors (as we thought we would have to) but during the recent sprint, we discovered that we may be able to detect some of these errors in a way that resembles subset errors:
- `ui/hrtb/hrtb-just-for-static.rs` -> 3 errors in NLL, 2 in polonius: a missing error about HRTB + needing to outlive 'static
- `ui/issues/issue-26217.rs` -> missing HRTB that makes the test compile instead of emitting an error

We'll keep talking about this at the next sprint as well.

cc `@rust-lang/wg-polonius` r? `@nikomatsakis`
2021-08-18 05:50:55 +00:00
Eric Huss b5cbf2ffef Update cargo 2021-08-17 17:38:07 -07:00
bors d83da1d05d Auto merge of #88083 - m-ou-se:non-fmt-panics-suggest-debug, r=estebank
Improve non_fmt_panics suggestion based on trait impls.

This improves the non_fmt_panics lint suggestions by checking first which trait (Display or Debug) are actually implemented on the type.

Fixes https://github.com/rust-lang/rust/issues/87313

Fixes https://github.com/rust-lang/rust/issues/87999

Before:

```
help: add a "{}" format string to Display the message
  |
2 |     panic!("{}", Some(1));
  |            +++++
help: or use std::panic::panic_any instead
  |
2 |     std::panic::panic_any(Some(1));
  |     ~~~~~~~~~~~~~~~~~~~~~
```

After:

```
help: add a "{:?}" format string to use the Debug implementation of `Option<i32>`
  |
2 |     panic!("{:?}", Some(1));
  |            +++++++
help: or use std::panic::panic_any instead
  |
2 |     std::panic::panic_any(Some(1));
  |     ~~~~~~~~~~~~~~~~~~~~~
```

r? `@estebank`
2021-08-17 16:43:40 +00:00
Mara Bos 280ac7f49f
Rollup merge of #88052 - bjorn3:update_redox_syscall, r=Mark-Simulacrum
Update redox_syscall

The currently pinned version doesn't compile with the latest rustc nightly

cc ``@jackpot51``
2021-08-16 23:37:31 +02:00
Mara Bos 0a313250a4 Improve non_fmt_panics suggestion based on trait impls. 2021-08-16 17:25:35 +02:00
bors 92f3753b07 Auto merge of #84039 - jyn514:uplift-atomic-ordering, r=wesleywiser
Uplift the invalid_atomic_ordering lint from clippy to rustc

This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.

r? `@lcnr` since you reviewed the last one, but feel free to reassign.

---

This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.

As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.

As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.

In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?

---

Some notes on the code for reviewers / others below

## Changes from clippy

The code is changed from [the implementation in clippy](68cf94f6a6/clippy_lints/src/atomic_ordering.rs) in the following ways:

1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
    - It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
    - There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
    - I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
    - These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
    - grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
    - function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
    - avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).

## Potential issues

(This is just about the code in this PR, not conceptual issues with the lint or anything)

1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
    - It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.

2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
    - I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.

3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.

4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).
2021-08-16 06:36:13 +00:00
Thom Chiovoloni 402a9c9f5e Uplift the invalid_atomic_ordering lint from clippy to rustc
- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead

  I ran into tons of trouble with this because apparently the change to
  store HIR attrs in a side table also gave the DefIds of the
  constructor instead of the variant itself. So I had to change
  `matches_ordering` to also check the grandparent of the defid as well.

- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
  Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches

  This prevents an ICE when there aren't enough arguments.

- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`

  The functions take values, so this couldn't ever be anything else.

- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow
2021-08-16 03:55:27 +00:00
bjorn3 856dd71bac
Update redox_syscall
The currently pinned version doesn't compile with the latest rustc nightly
2021-08-15 18:40:40 +02:00
Rémy Rakic 2cf4b87393 De-dupe NLL HRTB diagnostics' use of type_op_prove_predicate 2021-08-15 14:49:36 +02:00
Stefan Lankes bbb6cb8969 switch to the latest version of hermit-abi 2021-08-13 13:05:13 +02:00
bors 6bed1f0bc3 Auto merge of #87666 - ivmarkov:master, r=Amanieu
STD support for the ESP-IDF framework

Dear all,

This PR is implementing libStd support for the [ESP-IDF](https://github.com/espressif/esp-idf) newlib-based framework, which is the open source SDK provided by Espressif for their MCU family (esp32, esp32s2, esp32c3 and all other forthcoming ones).

Note that this PR has a [sibling PR](https://github.com/rust-lang/libc/pull/2310) against the libc crate, which implements proper declarations for all ESP-IDF APIs which are necessary for libStd support.

# Implementation approach

The ESP-IDF framework - despite being bare metal - offers a relatively complete POSIX API based on newlib. `pthread`, BSD sockets, file descriptors, and even a small file-system VFS layer. Perhaps the only significant exception is the lack of support for processes, which is to be expected of course on bare metal.

Therefore, the libStd support is implemented as a set of (hopefully small) changes to the `sys/unix` family of modules, in the form of conditional-compilation branches based either on `target_os = "espidf"` or in a couple of cases - based on `target_env = "newlib"` (the latter was already there actually and is not part of this patch).

The PR also contains two new targets:
- `riscv32imc-esp-espidf`
- `riscv32imac-esp-espidf`

... which are essentially copies of `riscv32imc-unknown-none-elf` and `riscv32imac-unknown-none-elf`, but enriched with proper `linker`, `linker_flavor`, `families`, `os`, `env` etc. specifications so that (a) the proper conditional compilation branches in libStd are selected when compiling with these targets and (b) the correct linker is used.

Since support for atomics is a precondition for libStd, the `riscv32imc-esp-espidf` target additionally is configured in such a way, so as to emit libcalls to the `__sync*` & `__atomic*` GCC functions, which are already implemented in the ESP-IDF framework. If this modification is not acceptable, we can also live with only the `riscv32imac-esp-espidf` target as well.  While the RiscV chips of Espressif lack native atomics support, the relevant instructions are transparently emulated in the ESP-IDF framework using invalid instruction trap. This modification was implemented specifically with Rust support in mind.

# Target maintainers

In case this PR eventually gets merged, you can list myself as a Target Maintainer.

More importantly, Espressif (the chip vendor) is now actively involved and [embracing](https://github.com/espressif/rust-esp32-example/blob/main/docs/rust-on-xtensa.md) all [Rust-related efforts](https://github.com/esp-rs) which were originally a community effort. In light of that, I suppose `@MabezDev` - who initiated the Rust-on-Espressif efforts back in time and who now works for Espressif won't object to being listed as a maintainer as well.

**EDIT:** I was hinted (thanks, `@Urgau)` that answering the Tier 3 policy explicitly might be helpful. Answers below.

# Tier 3 Target Policy - answers

> A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

Hopefully, the changes introduced by the ESP-IDF libStd support are rather on the small side. They are completely contained within the `sys/unix` set of modules (that is, aside from the obviously necessary one-liners in the `unwind` crate and in `build.rs`).

> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

`@ivmarkov`
`@MabezDev`

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

The two introduced targets follow as much as possible the naming conventions of the other targets. I.e. taking the bare-metal `riscv32imac_unknown_none_elf` as a base:
* The name of the new target was derived by replacing `none` with `espidf` to designate the `target_os`.
* `_elf` was removed, as the non-bare metal targets seem not to have it
* `-newlib` was deliberately NOT added at the end, as I believe the chance of having two simultaneously active separate targets for the ESP-IDF framework with different C libraries (say, newlib vs musl) is way too small
* Finally, we replaced the middle `unknown` with `esp` which is kind of the name of the whole chipset MCU family (and abbreviation from Espressif which is too long). It will stay `esp` for all RiscV32-based MCUs of the company, as they all use the riscv32imc instruction set. By necessity however (disambiguation), it will be `esp32` or `esp32s2` or `esp32s3` for the Xtensa-based MCUs as all of these have their own variation of the Xtensa architecture. (The Xtensa targets are not part of this PR, even though they would use 1:1 the same LibStd implementation provided here, as they depend on the upstreaming of the Xtensa architecture support in LLVM; this upstreaming this is currently in progress.)

There was also a preceding discussion on the topic [here](https://github.com/espressif/rust-esp32-example/issues/14).

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

We are explicitly putting an `-espidf` suffix to designate that the target is *specifically* for Rust + ESP-IDF

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

Agreed.

> The target must not introduce license incompatibilities.

To the best of our knowledge, it doesn't.

> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

MIT + Apache 2.0

> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.

Requirements are not changed for any other target.

> If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.

The targets are for bare-metal environment which is not hosting build tools or a compiler.

> Targets should not require proprietary (non-FOSS) components to link a functional binary or library.

The linker used by the targets is the GCC linker from the GCC toolchain cross-compiled for riscv. GNU GPL.

> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Agreed.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

The targets implement libStd almost in its entirety, except for the missing support for process, as this is a bare metal platform. The process `sys\unix` module is currently stubbed to return "not implemented" errors.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Target does not (yet) support running tests. We would gladly provide all documentation how to build for the target (where?). It is currently hosted in this [README.md](https://github.com/ivmarkov/rust-esp32-std-hello) file, but will likely be moved to the [esp-rs](https://github.com/esp-rs) organization. Since the build for the target is driven by cargo and [all other tooling is downloaded automatically during the build](https://github.com/esp-rs/esp-idf-sys/blob/master/build.rs), there is no need for extensive documentation.

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Agreed.

> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Agreed.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

To the best of our knowledge, we believe we are not breaking any other target (be it tier 1, 2 or 3).

> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

To the best of our knowledge, we have not introduced any unconditional use of a feature that affects any other target.

> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.

Agreed.
2021-08-12 10:33:14 +00:00