bors [Mon, 30 Aug 2021 22:21:01 +0000 (22:21 +0000)]
Auto merge of #88369 - lcnr:cec-rename, r=oli-obk
update const generics feature gates
**tl;dr: split const generics into three features: `adt_const_params`, `const_generics_defaults` and `generic_const_exprs`**
continuing the work of `@BoxyUwU` in #88324, this PR
- renames `feature(const_evaluatable_checked)` to `feature(generic_const_exprs)` which now doesn't need any other feature gate to work. Previously `feature(const_evaluatable_checked)` was only useful in combination with `feature(const_generics)`.
- completely removes `feature(lazy_normalization_consts)`. This feature only supplied the parents generics to anonymous constants, which is pretty useless as generic anon consts are only allowed with `feature(generic_const_exprs)` anyways.
- moves the ability to use additional const param types from `feature(const_generics)` into `feature(adt_const_params)`. As `feature(const_generics)` is now mostly useless without `feature(generic_const_exprs)` we also remove that feature flag.
- updates tests, removing duplicates and unnecessary revisions in some cases and also deletes all unused `*.stderr` files.
I not also remove the ordering restriction for const and type parameters if any of the three const generics features is active.
This ordering restriction feels like the only "real" use of the current `feature(const_generics)` right now so this change isn't a perfect solution, but as I intend to stabilize the ordering - and `feature(const_generics_defaults)` - in the very near future, I think this is acceptable for now.
---
cc `@rust-lang/project-const-generics` about the new feature names and this change in general.
I don't think we need any external approval for this change but I do intend to publish an update to the const generics tracking issue the day this PR lands, so I don't want this merged yet.
Apologies to whoever ends up reviewing this PR :sweat_smile: :heart:
bors [Mon, 30 Aug 2021 05:23:54 +0000 (05:23 +0000)]
Auto merge of #88456 - inquisitivecrystal:private-macro, r=jyn514
Fix: don't document private macros by default
As part of #88019, I made it so private macros are documented in `--document-private-items` mode. Unfortunately, it appears that I also accidentally made them be documented when *not* in `--document-private-items` mode. This PR fixes that and adds a regression test.
r? `@jyn514` (I hope you don't mind that I keep sending PRs your way)
bors [Sun, 29 Aug 2021 22:54:26 +0000 (22:54 +0000)]
Auto merge of #88337 - eddyb:field-failure-is-not-an-option, r=nagisa
rustc_target: `TyAndLayout::field` should never error.
This refactor (making `TyAndLayout::field` return `TyAndLayout` without any `Result` around it) is based on a simple observation, regarding `TyAndLayout::field`:
If `cx.layout_of(ty)` succeeds (for some `cx` and `ty`), then `.field(cx, i)` on the resulting `TyAndLayout` should *always* succeed in computing `cx.layout_of(field_ty)` (where `field_ty` is the type of the `i`th field of `ty`).
The reason for this is that no matter which field is chosen, `cx.layout_of(field_ty)` *will have already been computed*, as part of computing `cx.layout_of(ty)`, as we cannot determine the layout of *any* type without considering the layouts of *all* of its fields.
And so it should be fine to turn any errors into ICEs, since they likely indicate a `cx` mismatch, or some other edge case that is due to a compiler bug (as opposed to ever being an user-facing error).
<hr/>
Each commit should probably be reviewed separately, though note that there's some `where` clauses (in `rustc_target::abi::call::*`) that change in most commits.
bors [Sun, 29 Aug 2021 20:27:14 +0000 (20:27 +0000)]
Auto merge of #88280 - sexxi-goose:non-exhaustive, r=nikomatsakis
Handle match statements with non exhaustive variants in closures
This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.
If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.
Guillaume Gomez [Sun, 29 Aug 2021 14:25:35 +0000 (16:25 +0200)]
Rollup merge of #88411 - Aaron1011:remove-session-if-let, r=estebank
Remove `Session.if_let_suggestions`
We can instead if either the LHS or RHS types contain
`TyKind::Error`. In addition to covering the case where
we would have previously updated `if_let_suggestions`, this might
also prevent redundant errors in other cases as well.
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
Guillaume Gomez [Sun, 29 Aug 2021 14:25:32 +0000 (16:25 +0200)]
Rollup merge of #88387 - ehuss:remove-rustfix-tests, r=Mark-Simulacrum
Remove vestigial rustfix tests.
The directory `src/test/rustfix` is not actually tested. It looks like a mistake was made when rustfix tests were originally introduced in #50084. In commit 6f2d023028bbd666be2c211b923b32faf10a41da they were moved to `src/test/ui`, but the tests in the original directory weren't deleted.
This PR refactors the implementation of `markdown_summary_with_limit()`,
separating the logic of determining when the limit has been reached from
the actual rendering process.
The main advantage of the new approach is that it guarantees that all
HTML tags are closed, whereas the previous implementation could generate
tags that were never closed. It also ensures that no empty tags are
generated (e.g., `<em></em>`).
The new implementation consists of a general-purpose struct
`HtmlWithLimit` that manages the length-limiting logic and a function
`markdown_summary_with_limit()` that renders Markdown to HTML using the
struct.
bors [Sun, 29 Aug 2021 12:38:05 +0000 (12:38 +0000)]
Auto merge of #88208 - petrochenkov:lowspan, r=Aaron1011
ast_lowering: Introduce `lower_span` for catching all spans entering HIR
This PR cherry-picks the `fn lower_span` change from https://github.com/rust-lang/rust/pull/84373.
I also introduced `fn lower_ident` for lowering spans in identifiers, and audited places where HIR structures with spans or identifiers are constructed and added a few missing `lower_span`s/`lower_ident`s.
Having a hook for spans entering HIR can be useful for things other than https://github.com/rust-lang/rust/pull/84373, e.g. https://github.com/rust-lang/rust/issues/35148.
I also want to check whether this change causes perf regressions due to some accidental inlining issues.
bors [Sun, 29 Aug 2021 04:51:14 +0000 (04:51 +0000)]
Auto merge of #88250 - rusticstuff:macos-lld, r=nagisa
Make `-Z gcc-ld=lld` work for Apple targets
`-Z gcc-ld=lld` was introduced in #85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work.
In order to solve this patch does:
* Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format.
* Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld.
* If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation.
bors [Sat, 28 Aug 2021 23:39:02 +0000 (23:39 +0000)]
Auto merge of #87921 - kellerkindt:master, r=kennytm
Add Saturating type (based on Wrapping type)
Tracking #87920
### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->
- [x] ~`impl Div for Saturating<T>` falls back on inner integer division - which seems alright?~
- [x] add `saturating_div`? (to respect division by `-1`)
- [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl`, `ShlAssign`, `Shr` and `ShrAssign`?
- [naively](3f7d2ce28f8cf4dec56bf65fa2e6da0cf329ec55)
- [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~
- [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`?
- [x] `Saturating::rotate_left`
- [x] `Saturating::rotate_right`
- [x] `Not`
- [x] `BitXorOr` and `BitXorOrAssign`
- [x] `BitOr` and `BitOrAssign`
- [x] `BitAnd` and `BitAndAssign`
- [x] `Saturating::swap_bytes`
- [x] `Saturating::reverse_bits`
bors [Sat, 28 Aug 2021 18:17:29 +0000 (18:17 +0000)]
Auto merge of #85600 - 12101111:rustbuild-libunwind, r=petrochenkov
build llvm libunwind.a in rustbuild
This PR move the building of llvm-libunwind from build script of libunwind to rustbuild, so user don't need a C compiler and recompile this C/C++ library when using build-std, and user can use codegen flags `link-self-contained` and cargo flag `build-std-features` to control the behavior of libunwind linking.
bors [Sat, 28 Aug 2021 15:36:38 +0000 (15:36 +0000)]
Auto merge of #88390 - sexxi-goose:missing-case, r=nikomatsakis
Add missing const edge case
We don't "process" const so we need to check for additional cases when the PatKind is a Path. We need to make sure that if there is only one variant that there is no field. If there is one or more field, we will want to borrow the match scrutinee
bors [Sat, 28 Aug 2021 13:10:26 +0000 (13:10 +0000)]
Auto merge of #88388 - ldm0:outliner, r=nikic
Revert "Disable the machine outliner by default"
The fix commit is already in the fork: https://github.com/rust-lang/llvm-project/commit/6c78dbd4ca1f
Linked:
- https://github.com/rust-lang/rust/issues/85351
- https://github.com/rust-lang/rust/pull/86020
bors [Sat, 28 Aug 2021 10:45:28 +0000 (10:45 +0000)]
Auto merge of #88019 - inquisitivecrystal:macro-def, r=cjgillot
Treat macros as HIR items
Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over, which I've attempted to lay out below. By normalizing the treatment of macro items, this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information, see #87406.
r? `@cjgillot`
## Backwards incompatibility
This is backwards incompatible in one small way. Due to a mistake, it was previously possible to apply stability attributes to an exported macro, even without enabling the `staged_api` feature. This never should have worked. After this PR, it will error, as it should. We could make it a warning instead, but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates, so I'm not thrilled about the idea.
## Notes for reviewers
### Commit seperation
I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect, but it's better than looking at the combined diff, which is quite overwhelming. The compiler and standard library build after each commit, although tests do not necessarily pass and tools do not necessarily build till the end of the series.
### Special cases
There are a few special cases that remain after this change. Here are the notable ones I remember:
1. Visibility works a bit differently for `macro_rules!` macros than other items, since they aren't generally marked with `pub` but instead with `#[macro_export]`.
2. Since `#[macro_export]` macros always have paths at the top level of the crate, some additional handling needs to be done on the reexport to top level.
### Performance impact
I don't know for sure, but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance, some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :)
## Issues resolved
This resolves #87406 (the tracking issue for this change). It also fixes several bugs:
bors [Sat, 28 Aug 2021 08:04:41 +0000 (08:04 +0000)]
Auto merge of #88245 - Sl1mb0:s390-asm, r=Amanieu
S390x inline asm
This adds register definitions and constraint codes for the s390x general and floating point registers necessary for fixing #85931; as well as a few tests.
Further testing is needed, but I am a little unsure of what specific tests should be added to `src/test/assembly/asm/s390x.rs` to address this.
Aaron Hill [Fri, 27 Aug 2021 23:28:22 +0000 (18:28 -0500)]
Remove `Session.if_let_suggestions`
We can instead if either the LHS or RHS types contain
`TyKind::Error`. In addition to covering the case where
we would have previously updated `if_let_suggestions`, this might
also prevent redundant errors in other cases as well.
bors [Fri, 27 Aug 2021 21:35:08 +0000 (21:35 +0000)]
Auto merge of #88328 - fee1-dead:not-quite-const, r=oli-obk
Introduce `~const`
- [x] Removed `?const` and change uses of `?const`
- [x] Added `~const` to the AST. It is gated behind const_trait_impl.
- [x] Validate `~const` in ast_validation.
- [x] Update UI Tests
- [x] Add enum `BoundConstness` (With variants `NotConst` and
`ConstIfConst` allowing future extensions)
- [x] Adjust trait selection and pre-existing code to use `BoundConstness`.
- [ ] Optional steps for this PR
- [x] Fix #88155
- [x] ~~Do something with constness bounds in chalk~~ Must be done to rust-lang/chalk (just tried to refactor, there are a lot of errors to resolve :( )
- [ ] Adjust Error messages for `~const` bounds that can't be satisfied.
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
bors [Fri, 27 Aug 2021 09:18:14 +0000 (09:18 +0000)]
Auto merge of #88227 - 12101111:nobundle-link-order, r=petrochenkov
Adjust linking order of static nobundle libraries
Link the static libraries with "-bundle" modifier from upstream rust crate right after linking this rust crate.
Some linker such as GNU linker `ld.bdf` treat order of linking as order of dependency.
After this change, static libraries with "-bundle" modifier is linked in the same order as "+bundle" modifier.
So we can change the value of "bundle" modifier without causing linking error.
Deadbeef [Wed, 25 Aug 2021 11:53:16 +0000 (11:53 +0000)]
Introduce `~const`
- [x] Removed `?const` and change uses of `?const`
- [x] Added `~const` to the AST. It is gated behind const_trait_impl.
- [x] Validate `~const` in ast_validation.
- [ ] Add enum `BoundConstness` to the HIR. (With variants `NotConst` and
`ConstIfConst` allowing future extensions)
- [ ] Adjust trait selection and pre-existing code to use `BoundConstness`.
- [ ] Optional steps (*for this PR, obviously*)
- [ ] Fix #88155
- [ ] Do something with constness bounds in chalk
bors [Fri, 27 Aug 2021 03:48:04 +0000 (03:48 +0000)]
Auto merge of #88278 - ehuss:update-cargo, r=ehuss
Update cargo
19 commits in e96bdb0c3d0a418e7fcd7fbd69be08abf830b4bc..f559c109cc79fe413a8535fb620a5a58b3823d94
2021-08-17 22:58:47 +0000 to 2021-08-26 22:54:55 +0000
- Fix test not to rely on `cargo` in PATH. (rust-lang/cargo#9843)
- Improve resolver message to include dependency requirements (rust-lang/cargo#9827)
- Add hint for cargo metadata in environment section (rust-lang/cargo#9836)
- Fix panic with build-std of a proc-macro. (rust-lang/cargo#9834)
- Fix typos “a”→“an” (rust-lang/cargo#9821)
- Fix typo in git-authentication.md (rust-lang/cargo#9832)
- Add some debug logging for `cargo fix` (rust-lang/cargo#9831)
- Add documentation about third-party registries. (rust-lang/cargo#9830)
- unset the FIX_ENV when executing the real rustc (rust-lang/cargo#9818)
- Allow crate download by checksum (rust-lang/cargo#9801)
- Emit warning for migrating to unstable edition in stable channel (rust-lang/cargo#9792)
- Warning for no lib dependencies (rust-lang/cargo#9771)
- Temporarily disable extern-html-root-url test. (rust-lang/cargo#9824)
- Move `tmp` test directory. (rust-lang/cargo#9814)
- Fix test incorrectly validating CARGO_PKG_LICENSE_FILE. (rust-lang/cargo#9813)
- Implement `[future-incompat-report]` config section (rust-lang/cargo#9774)
- Bump curl. (rust-lang/cargo#9809)
- Determine packages to install prior to installing (rust-lang/cargo#9793)
- Show feature resolver differences for dev-dependencies. (rust-lang/cargo#9803)
bors [Fri, 27 Aug 2021 01:07:17 +0000 (01:07 +0000)]
Auto merge of #88371 - Manishearth:rollup-pkkjsme, r=Manishearth
Rollup of 11 pull requests
Successful merges:
- #87832 (Fix debugger stepping behavior with `match` expressions)
- #88123 (Make spans for tuple patterns in E0023 more precise)
- #88215 (Reland #83738: "rustdoc: Don't load all extern crates unconditionally")
- #88216 (Don't stabilize creation of TryReserveError instances)
- #88270 (Handle type ascription type ops in NLL HRTB diagnostics)
- #88289 (Fixes for LLVM change 0f45c16f2caa7c035e5c3edd40af9e0d51ad6ba7)
- #88320 (type_implements_trait consider obligation failure on overflow)
- #88332 (Add argument types tait tests)
- #88340 (Add `c_size_t` and `c_ssize_t` to `std::os::raw`.)
- #88346 (Revert "Add type of a let tait test impl trait straight in let")
- #88348 (Add field types tait tests)
bors [Thu, 26 Aug 2021 22:26:23 +0000 (22:26 +0000)]
Auto merge of #87280 - lcnr:lazy-anon-const-default-substs, r=nikomatsakis
lazily "compute" anon const default substs
Continuing the work of #83086, this implements the discussed solution for the [unused substs problem](https://github.com/rust-lang/project-const-generics/blob/master/design-docs/anon-const-substs.md#unused-substs). As of now, anonymous constants inherit all of their parents generics, even if they do not use them, e.g. in `fn foo<T, const N: usize>() -> [T; N + 1]`, the array length has `T` as a generic parameter even though it doesn't use it. These *unused substs* cause some backwards incompatible, and imo incorrect behavior, e.g. #78369.
---
We do not actually filter any generic parameters here and the `default_anon_const_substs` query still a dummy which only checks that
- we now prevent the previously existing query cycles and are able to call `predicates_of(parent)` when computing the substs of anonymous constants
- the default anon consts substs only include the typeflags we assume it does.
Implementing that filtering will be left as future work.
---
The idea of this PR is to delay the creation of the anon const substs until after we've computed `predicates_of` for the parent of the anon const. As the predicates of the parent can however contain the anon const we still have to create a `ty::Const` for it.
We do this by changing the substs field of `ty::Unevaluated` to an option and modifying accesses to instead call the method `unevaluated.substs(tcx)` which returns the substs as before. If the substs - now `substs_` - of `ty::Unevaluated` are `None`, it means that the anon const currently has its default substs, i.e. the substs it has when first constructed, which are the generic parameters it has available. To be able to call `unevaluated.substs(tcx)` in a `TypeVisitor`, we add the non-defaulted method `fn tcx_for_anon_const_substs(&self) -> Option<TyCtxt<'tcx>>`. In case `tcx_for_anon_const_substs` returns `None`, unknown anon const default substs are skipped entirely.
Even when `substs_` is `None` we still have to treat the constant as if it has its default substs. To do this, `TypeFlags` are modified so that it is clear whether they can still change when *exposing* any anon const default substs. A new flag, `HAS_UNKNOWN_DEFAULT_CONST_SUBSTS`, is added in case some default flags are missing.
The rest of this PR are some smaller changes to either not cause cycles by trying to access the default anon const substs too early or to be able to access the `tcx` in previously unused locations.
cc `@rust-lang/project-const-generics`
r? `@nikomatsakis`
This is similar to what I was commenting here https://github.com/rust-lang/rust/pull/88332#discussion_r695939901
These is not part of TAITs so should not live in type-alias-impl-trait test directory.
I'm going to avoid adding this kind of tests in `type-alias-impl-trait` test directory and avoid thinking about them in this pass.