Commit Graph

154846 Commits

Author SHA1 Message Date
the8472
8d95bb2146
Rollup merge of #89126 - FabianWolff:issue-89088, r=petrochenkov
Fix ICE when `indirect_structural_match` is allowed

Fixes #89088. The ICE is caused by `delay_good_path_bug()`, which is called (indirectly) from a `format!()` macro invocation. I have moved the macro invocation into the `decorate` closure of `struct_span_lint_hir()`, so that the macro is only invoked if the lint is not allowed (i.e., causes at least a warning, and thus prevents `delay_good_path_bug()` from firing).
2021-09-21 22:54:06 +02:00
the8472
74cdd64ac9
Rollup merge of #89115 - lnicola:rust-analyzer-2021-09-20, r=Mark-Simulacrum
⬆️ rust-analyzer

`@bors` r+ rollup
2021-09-21 22:54:05 +02:00
the8472
8a6e9cf074
Rollup merge of #89114 - dequbed:c-char, r=yaahc
Fixes a technicality regarding the size of C's `char` type

Specifically, ISO/IEC 9899:2018 — better known as "C18" — (and at least
C11, C99 and C89) do not specify the size of `byte` in bits.
Section 3.6 defines "byte" as "addressable unit of data storage" while
section 6.2.5 ("Types") only defines "char" as "large enough to store
any member of the basic execution set" giving it a lower bound of 7 bit
(since there are 96 characters in the basic execution set).
With section 6.5.3.4 paragraph 4 "When sizeof is applied to an operant
that has type char […] the result is 1" you could read this as the size
of `char` in bits being defined as exactly the same as the number of
bits in a byte but it's also valid to read that as an exception.

In general implementations take `char` as the smallest unit of
addressable memory, which for modern byte-addressed architectures is
overwhelmingly 8 bits to the point of this convention being completely
cemented into just about all of our software.

So is any of this actually relevant at all? I hope not. I sincerely hope
that this never, ever comes up.
But if for some reason a poor rustacean is having to interface with C
code running on a Cray X1 that in 2003 is still doing word-addressed
memory with 64-bit chars and they trust the docs here blindly it will
blow up in her face. And I'll be truly sorry for her to have to deal
with … all of that.
2021-09-21 22:54:04 +02:00
the8472
ecfdadcef9
Rollup merge of #89113 - BoxyUwU:incr-comp-thir-act, r=lcnr
dont `.ensure()` the `thir_abstract_const` query call in `mir_build`

might fix an ICE seen in #89022 (note: this PR does not close that issue) about attempting to read stolen thir. I couldn't repro the ICE but this `.ensure` seems sus anyway.

r? `@lcnr`
2021-09-21 22:54:03 +02:00
the8472
a8633ebcac
Rollup merge of #89096 - daira:improve-ninja-error-message, r=jyn514
[bootstrap] Improve the error message when `ninja` is not found to link to installation instructions

fixes #89091

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-21 22:54:02 +02:00
the8472
d7de8d2b53
Rollup merge of #89086 - WaffleLapkin:stabilize_iter_map_while, r=kennytm
Stabilize `Iterator::map_while`

Per the FCP: https://github.com/rust-lang/rust/issues/68537#issuecomment-922385035

This PR stabilizes `Iterator::map_while` and `iter::MapWhile` in Rust 1.57.
2021-09-21 22:54:01 +02:00
the8472
9f50c87267
Rollup merge of #89078 - camsteffen:map-ref, r=cjgillot
Cleanup: Remove needless reference in ParentHirIterator

It forces an intermediate binding of `Map` which is a Copy type.
2021-09-21 22:54:00 +02:00
the8472
051168b876
Rollup merge of #89015 - klensy:escape-def, r=Mark-Simulacrum
core::ascii::escape_default: reduce struct size
2021-09-21 22:53:59 +02:00
the8472
c2cdba42b9
Rollup merge of #88795 - FabianWolff:issue-88684, r=wesleywiser
Print a note if a character literal contains a variation selector

Fixes #88684.
2021-09-21 22:53:58 +02:00
bors
840acd378a Auto merge of #88981 - durin42:llvm-14-crc32, r=nagisa
rustc_codegen_llvm: make sse4.2 imply crc32 for LLVM 14

This fixes compiling things like the `snap` crate after
https://reviews.llvm.org/D105462. I added a test that verifies the
additional attribute gets specified, and confirmed that I can build
cargo with both LLVM 13 and 14 with this change applied.

r? `@nagisa` cc `@nikic`
2021-09-21 16:13:24 +00:00
bors
7743c9fadd Auto merge of #89125 - Aaron1011:remove-intercrate-cache, r=jackh726
Don't use projection cache or candidate cache in intercrate mode

Fixes #88969

It appears that *just* disabling the evaluation cache (in #88994)
leads to other issues involving intercrate mode caching. I suspect
that since we now always end up performing the full evaluation
in intercrate mode, we end up 'polluting' the candidate and projection
caches with results that depend on being in intercrate mode in some way.
Previously, we might have hit a cached evaluation (stored during
non-intercrate mode), and skipped doing this extra work in
intercrate mode.

The whole situation with intercrate mode caching is turning into
a mess. Ideally, we would remove intercrate mode entirely - however,
this might require waiting on Chalk.
2021-09-21 13:25:14 +00:00
bors
dda2a0eca4 Auto merge of #89045 - oli-obk:lazy_normalization_in_opaque_types, r=nikomatsakis
Register normalization obligations instead of immediately normalizing in opaque type instantiation

For lazy TAIT we will need to instantiate opaque types from within `rustc_infer`, which cannot invoke normalization methods (they are in `rustc_trait_resolution`). So before we move the logic over to `rustc_infer`, we need make sure no normalization happens anymore. This PR resolves that by just registering normalization obligations and continuing.

This PR is best reviewed commit by commit

I also included f7ad36e which is just an independent cleanup that touches the same code and reduces diagnostics noise a bit

r? `@nikomatsakis` cc `@spastorino`
2021-09-21 10:33:15 +00:00
bors
49c0861ed0 Auto merge of #87234 - cjgillot:lower-mono, r=petrochenkov
Lower only one HIR owner at a time

Based on https://github.com/rust-lang/rust/pull/83723
Additional diff is here: https://github.com/cjgillot/rust/compare/ownernode...lower-mono

Lowering is very tangled and has a tendency to intertwine the transformation of different items. This PR aims at simplifying the logic by:
- moving global analyses to the resolver (item_generics_num_lifetimes, proc_macros, trait_impls);
- removing a few special cases (non-exported macros and use statements);
- restricting the amount of available information at any one time;
- avoiding back-and-forth between different owners: an item must now be lowered all at once, and its parent cannot refer to its nodes.

I also removed the sorting of bodies by span.  The diagnostic ordering changes marginally, since definitions are pretty much sorted already according to the AST. This uncovered a subtlety in thir-unsafeck.

(While these items could logically be in different PRs, the dependency between commits and the amount of conflicts force a monolithic PR.)
2021-09-21 07:52:15 +00:00
bors
e7958d35ca Auto merge of #87830 - hkmatsumoto:suggest-brackets-for-array-esque-block-expr, r=estebank
Suggest replacing braces for brackets on array-esque invalid block expr

Newcomers may write `{1, 2, 3}` for making arrays, and the current error message is not informative enough to quickly convince them what is needed to fix the error.

This PR implements a diagnostic for this case, and its output looks like this:
```text
error: this code is interpreted as a block expression, not an array
 --> src/lib.rs:1:22
  |
1 |   const FOO: [u8; 3] = {
  |  ______________________^
2 | |     1, 2, 3
3 | | };
  | |_^
  |
  = note: to define an array, one would use square brackets instead of curly braces
help: try using [] instead of {}
  |
1 | const FOO: [u8; 3] = [
2 |     1, 2, 3
3 | ];
  |
```

Fix #87672
2021-09-21 00:34:10 +00:00
Aaron Hill
6dbb9d4eee
Don't use projection cache or candidate cache in intercrate mode
Fixes #88969

It appears that *just* disabling the evaluation cache (in #88994)
leads to other issues involving intercrate mode caching. I suspect
that since we now always end up performing the full evaluation
in intercrate mode, we end up 'polluting' the candidate and projection
caches with results that depend on being in intercrate mode in some way.
Previously, we might have hit a cached evaluation (stored during
non-intercrate mode), and skipped doing this extra work in
intercrate mode.

The whole situation with intercrate mode caching is turning into
a mess. Ideally, we would remove intercrate mode entirely - however,
this might require waiting on Chalk.
2021-09-20 14:37:11 -05:00
Fabian Wolff
402ebc72b3 Fix ICE when indirect_structural_match is allowed 2021-09-20 21:25:44 +02:00
bors
60e70cc909 Auto merge of #89117 - michaelwoerister:update-to-odht-0.3, r=wesleywiser
Update odht crate to 0.3.0

This version of odht contains a potential fix for #89085.

r? `@wesleywiser`
2021-09-20 17:38:07 +00:00
Augie Fackler
4185b76dc3 rustc_codegen_llvm: make sse4.2 imply crc32 for LLVM 14
This fixes compiling things like the `snap` crate after
https://reviews.llvm.org/D105462. I added a test that verifies the
additional attribute gets specified, and confirmed that I can build
cargo with both LLVM 13 and 14 with this change applied.
2021-09-20 11:31:55 -04:00
bors
3bb9eecf07 Auto merge of #89069 - bjorn3:optimize_sharded_new, r=Mark-Simulacrum
Use <[T; N]>::map in Sharded instead of SmallVec and unsafe code

This results in a lot less assembly
2021-09-20 14:33:00 +00:00
Oli Scherer
afb7472bcc Add a doc comment to infer_projection 2021-09-20 14:16:19 +00:00
Oli Scherer
b952ada0ae Use ty::Error for opaque types with errors in its bounds.
This reduces unhelpful diagnostics down the road.
2021-09-20 14:15:36 +00:00
Oli Scherer
34de78fd81 Generate inference vars and obligations for projections in opaque types instead of trying to normalize them. 2021-09-20 14:15:36 +00:00
Oli Scherer
5fb1a65215 Inline a function that is only called once 2021-09-20 14:15:36 +00:00
Oli Scherer
5afeed05e8 Use tracing debugging in fold_opaque_ty 2021-09-20 14:15:36 +00:00
Oli Scherer
dfb11a8a26 Add helper function to InferCtxt that generates inference vars for unresolved associated types 2021-09-20 13:57:56 +00: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
Laurențiu Nicola
514b8ba0ba ⬆️ rust-analyzer 2021-09-20 15:45:46 +03:00
Ellen
5fdb9e4cf4 no ensure 2021-09-20 09:30:28 +01:00
bors
db1fb85cff Auto merge of #88321 - glaubitz:m68k-linux, r=wesleywiser
Add initial support for m68k

This patch series adds initial support for m68k making use of the new M68k
backend introduced with LLVM-13. Additional changes will be needed to be
able to actually use the backend for this target.
2021-09-20 07:21:05 +00:00
Camille GILLOT
11024b26bf Bless incremental tests. 2021-09-20 08:32:21 +02:00
Camille GILLOT
a1a35576eb Make with_hir_id_owner responsible for registering the item. 2021-09-20 08:31:16 +02:00
Nadja Reitzenstein
23c608f3a1 Fix a technicality regarding the size of C's char type
Specifically, ISO/IEC 9899:2018 — better known as "C18" — (and at least
C11, C99 and C89) do not specify the size of `byte` in bits.
Section 3.6 defines "byte" as "addressable unit of data storage" while
section 6.2.5 ("Types") only defines "char" as "large enough to store
any member of the basic execution set" giving it a lower bound of 7 bit
(since there are 96 characters in the basic execution set).
With section 6.5.3.4 paragraph 4 "When sizeof is applied to an operant
that has type char […] the result is 1" you could read this as the size
of `char` in bits being defined as exactly the same as the number of
bits in a byte but it's also valid to read that as an exception.

In general implementations take `char` as the smallest unit of
addressable memory, which for modern byte-addressed architectures is
overwhelmingly 8 bits to the point of this convention being completely
cemented into just about all of our software.

So is any of this actually relevant at all? I hope not. I sincerely hope
that this never, ever comes up.
But if for some reason a poor rustacean is having to interface with C
code running on a Cray X1 that in 2003 is still doing word-addressed
memory with 64-bit words and they trust the docs here blindly it will
blow up in her face. And I'll be truly sorry for her to have to deal
with … all of that.
2021-09-20 08:19:13 +02:00
bors
e71925aab9 Auto merge of #88842 - wesleywiser:fix_dbg_tests_windows_sdk, r=michaelwoerister
Fix debuginfo tests for the latest version of the Windows SDK.

Re-enable the tests that were disabled to fix CI.

Changes:
- Cdb now correctly visualizes enums.
- Cdb doesn't render emoji characters in `OSStr` anymore.
- Cdb doesn't always render `str` correctly (#88840)
2021-09-20 03:53:10 +00:00
bors
0c0826c3e2 Auto merge of #88708 - Aaron1011:aggregate-usage, r=oli-obk
Add `ConstraintCategory::Usage` for handling aggregate construction

In some cases, we emit borrowcheck diagnostics pointing
at a particular field expression in a struct expression
(e.g. `MyStruct { field: my_expr }`). However, this
behavior currently relies on us choosing the
`ConstraintCategory::Boring` with the 'correct' span.
When adding additional variants to `ConstraintCategory`,
(or changing existing usages away from `ConstraintCategory::Boring`),
the current behavior can easily get broken, since a non-boring
constraint will get chosen over a boring one.

To make the diagnostic output less fragile, this commit
adds a `ConstraintCategory::Usage` variant. We use this variant
for the temporary assignments created for each field of
an aggregate we are constructing.

Using this new variant, we can emit a message mentioning
"this usage", emphasizing the fact that the error message
is related to the specific use site (in the struct expression).

This is preparation for additional work on improving NLL error messages
(see #57374)
2021-09-20 00:53:13 +00:00
Camille GILLOT
c1bac9229a Remove lower_node_id_with_owner. 2021-09-20 00:50:47 +02:00
Camille GILLOT
d7795d302a Do not store visibility in *ItemRef. 2021-09-20 00:29:53 +02:00
bors
91198820d7 Auto merge of #88575 - eddyb:fn-abi-queries, r=nagisa
Querify `FnAbi::of_{fn_ptr,instance}` as `fn_abi_of_{fn_ptr,instance}`.

*Note: opening this PR as draft because it's based on #88499*

This more or less replicates the `LayoutOf::layout_of` setup from #88499, to replace `FnAbi::of_{fn_ptr,instance}` with `FnAbiOf::fn_abi_of_{fn_ptr,instance}`, and also route them through queries (which `layout_of` has used for a while).

The two changes at the use sites (other than the names) are:
* return type is now wrapped in `&'tcx`
  * the value *is* interned, which may affect performance
* the `extra_args` list is now an interned `&'tcx ty::List<Ty<'tcx>>`
  * should be cheap (it's empty for anything other than C variadics)

Theoretically, a `FnAbiOfHelpers` implementer could choose to keep the `Result<...>` instead of eagerly erroring, but the only existing users of these APIs are codegen backends, so they don't (want to) take advantage of this.
At least miri could make use of this, since it prefers propagating errors (it "just" doesn't use `FnAbi` yet - cc `@RalfJung).`

The way this is done is probably less efficient than what is possible, because the queries handle the correctness-oriented API (i.e. the split into `fn` pointers vs instances), whereas a lower-level query could end up with more reuse between different instances with identical signatures.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
2021-09-19 21:39:47 +00:00
bors
5ecc8ad846 Auto merge of #89049 - Aaron1011:caching-sourcemap-assert, r=Mark-Simulacrum
Convert `debug_assert` to `assert` in `CachingSourceMapView`

I suspect that there's a bug somewhere in this code, which is
leading to the `predicates_of` ICE being seen in #89035
2021-09-19 18:54:31 +00:00
Daira Hopwood
23d6437128
Restore the suggestion to set ninja = false. 2021-09-19 19:50:08 +01:00
bors
7b5f95270f Auto merge of #88703 - cjgillot:lazymod, r=petrochenkov
Gather module items after lowering.

This avoids having a non-local analysis inside lowering.

By implementing `hir_module_items` using a visitor, we make sure that iterations and visitors are consistent.
2021-09-19 16:13:42 +00:00
Daira Hopwood
a627b4f2bf [bootstrap] Improve the error message when ninja is not found to link to installation instructions.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2021-09-19 14:50:58 +01:00
bors
697118d23e Auto merge of #88627 - cjgillot:noallocuse, r=petrochenkov
Do not preallocate HirIds

Part of https://github.com/rust-lang/rust/pull/87234

r? `@petrochenkov`
2021-09-19 13:44:18 +00:00
bors
08a0307b32 Auto merge of #89089 - JohnTitor:rollup-6s6mccx, r=JohnTitor
Rollup of 10 pull requests

Successful merges:

 - #87960 (Suggest replacing an inexisting field for an unmentioned field)
 - #88855 (Allow simd_shuffle to accept vectors of any length)
 - #88966 (Check for shadowing issues involving block labels)
 - #88996 (Fix linting when trailing macro expands to a trailing semi)
 - #89017 (fix potential race in AtomicU64 time monotonizer)
 - #89021 (Add a separate error for `dyn Trait` in `const fn`)
 - #89051 (Add intra-doc links and small changes to `std::os` to be more consistent)
 - #89053 (refactor: VecDeques IntoIter fields to private)
 - #89055 (Suggest better place to add call parentheses for method expressions wrapped in parentheses)
 - #89081 (Fix a typo)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-09-19 11:03:09 +00:00
Hirochika Matsumoto
21eff8f050 Suggest replacing braces for brackets on array-esque invalid block expr
Newcomers may write `{1, 2, 3}` for making arrays, and the current error
message is not informative enough to quickly convince them what is
needed to fix the error.
This PR implements a diagnostic for this case, and its output looks like
this:
```text
error: this code is interpreted as a block expression, not an array
 --> src/lib.rs:1:22
  |
1 |   const FOO: [u8; 3] = {
  |  ______________________^
2 | |     1, 2, 3
3 | | };
  | |_^
  |
  = note: to define an array, one would use square brackets instead of curly braces
help: try using [] instead of {}
  |
1 | const FOO: [u8; 3] = [
2 |     1, 2, 3
3 | ];
  |
```

Fix #87672
2021-09-19 20:01:23 +09:00
Yuki Okushi
4877ad3d12
Rollup merge of #89081 - ondra05:patch-1, r=dtolnay
Fix a typo

Removed extra spaces in front of commas
2021-09-19 17:31:35 +09:00
Yuki Okushi
441046af97
Rollup merge of #89055 - Kobzol:wrapped-method-expr-call-parens, r=wesleywiser
Suggest better place to add call parentheses for method expressions wrapped in parentheses

I wanted to improve the suggestion a bit to both remove the wrapping parentheses **and** add call parentheses by both calling `suggest_method_call` and using `multipart_suggestion`. But I very quickly ran into a problem where multiple overlapping machine applicable suggestions cannot be properly applied together. So I applied the suggestion from the issue and only added the call parentheses directly after the expression.

Fixes: https://github.com/rust-lang/rust/issues/89044
2021-09-19 17:31:35 +09:00
Yuki Okushi
e4dbe27235
Rollup merge of #89053 - DeveloperC286:into_iter_fields_to_private, r=Mark-Simulacrum
refactor: VecDeques IntoIter fields to private

Made the fields of VecDeque's IntoIter private by creating a IntoIter::from(...) function to create a new instance of IntoIter and migrating usage to use IntoIter::from(...).
2021-09-19 17:31:34 +09:00
Yuki Okushi
4366059124
Rollup merge of #89051 - schctl:master, r=jyn514
Add intra-doc links and small changes to `std::os` to be more consistent

I believe that a few items in `std::os` should be linked. I've also added a basic example in `std::os::windows`.
2021-09-19 17:31:33 +09:00
Yuki Okushi
61bfe3653b
Rollup merge of #89021 - WaffleLapkin:separate_error_for_dyn_trait_in_const_fn, r=estebank
Add a separate error for `dyn Trait` in `const fn`

Previously "trait bounds other than `Sized` on const fn parameters are unstable" error was used for both trait bounds (`<T: Trait>`) and trait objects (`dyn Trait`). This was pretty confusing.

This PR adds a separate error for trait objects: "trait objects in const fn are unstable". The error for trait bounds is otherwise intact.

This is follow up to #88907

r? ``@estebank``

``@rustbot`` label: +A-diagnostics
2021-09-19 17:31:33 +09:00
Yuki Okushi
91c5e7cbb6
Rollup merge of #89017 - the8472:fix-u64-time-monotonizer, r=kennytm
fix potential race in AtomicU64 time monotonizer

The AtomicU64-based monotonizer introduced in #83093 is incorrect because several threads could try to update the value concurrently and a thread which doesn't have the newest value among all the updates could win.

That bug probably has little real world impact since it doesn't make observed time worse than hardware clocks. The worst case would probably be a thread which has a clock that is behind by several cycles observing several inconsistent fixups, which should be similar to observing the unfiltered backslide in the first place.

New benchmarks, they don't look as good as the original PR but still an improvement compared to the mutex.
I don't know why the contended mutex case is faster now than in the previous benchmarks.

```
actually_monotonic() == true:
test time::tests::instant_contention_01_threads                   ... bench:          44 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:          45 ns/iter (+/- 0)
test time::tests::instant_contention_04_threads                   ... bench:          45 ns/iter (+/- 0)
test time::tests::instant_contention_08_threads                   ... bench:          45 ns/iter (+/- 0)
test time::tests::instant_contention_16_threads                   ... bench:          46 ns/iter (+/- 0)

atomic u64:
test time::tests::instant_contention_01_threads                   ... bench:          66 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:         287 ns/iter (+/- 14)
test time::tests::instant_contention_04_threads                   ... bench:         296 ns/iter (+/- 43)
test time::tests::instant_contention_08_threads                   ... bench:         604 ns/iter (+/- 163)
test time::tests::instant_contention_16_threads                   ... bench:       1,147 ns/iter (+/- 29)

mutex:
test time::tests::instant_contention_01_threads                   ... bench:          78 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:         652 ns/iter (+/- 275)
test time::tests::instant_contention_04_threads                   ... bench:         900 ns/iter (+/- 32)
test time::tests::instant_contention_08_threads                   ... bench:       1,927 ns/iter (+/- 62)
test time::tests::instant_contention_16_threads                   ... bench:       3,748 ns/iter (+/- 146)
```
2021-09-19 17:31:32 +09:00