bors [Sun, 1 May 2022 00:50:46 +0000 (00:50 +0000)]
Auto merge of #95362 - scottmcm:calloc-arrays, r=Mark-Simulacrum
Support arrays of zeros in Vec's __rust_alloc_zeroed optimization
I happened to notice in https://users.rust-lang.org/t/any-advantage-of-box-u64-16-16-16-over-vec-u64/73500/3?u=scottmcm that the calloc optimization wasn't applying to vectors-of-arrays, so here's the easy fix for that.
Auto merge of #96347 - estebank:issue-96292, r=compiler-errors
Erase type params when suggesting fully qualified path
When suggesting the use of a fully qualified path for a method call that
is ambiguous because it has multiple candidates, erase type params in
the resulting code, as they would result in an error when applied. We
replace them with `_` in the output to rely on inference. There might be
cases where this still produces slighlty incomplete suggestions, but it
otherwise produces many more errors in relatively common cases.
Auto merge of #93803 - cjgillot:unify-bounds, r=oli-obk
Handle generic bounds in a uniform way in HIR
Generic bounds in HIR used to be split between bounds in the parameter definition and bounds in a where clause. This PR attempts to store all of those as where predicates.
This effectively desugars
```rust
fn foo<T: Default, U>(x: impl Copy) where U: Clone
```
into
```rust
fn foo<T, U, _V>(x: _V) where T: Default, U: Clone, _V: Copy
```
(where _V is actually hidden and called "impl Copy").
I managed to make compiler warnings more uniform.
About rustdoc: is making this desugaring user-visible acceptable?
About clippy: I don't understand the subtle logic in the `needless-lifetimes` lint.
Computing the RPO of mir is not a low-cost thing, but it is duplicate in many places. In particular the `iterate_to_fixpoint` method which is called multiple times when computing the data flow.
This PR reduces the number of times the RPO is recalculated as much as possible, which should save some compile time.
Rollup merge of #96562 - michaelwoerister:path-remapping-fixes, r=oli-obk
Fix duplicate directory separator in --remap-path-prefix.
The compiler will currently emit duplicate directory separators when `--remap-path-prefix` has an exact match of the working directory and it is invoked with a relative path to the main source file. For example
will produce the path `abc//src/main.rs` in debuginfo. This is because `some_path.join("")` will append a directory separator to `some_path` and then LLVM does not check if the working directory already ends a directory separator before concatenating it with the relative path.
Rollup merge of #96560 - abrown:update-docs, r=Dylan-DPC
Remove unnecessary environment variable in cf-protection documentation
Before merging the `cf-protection` flag, it was necessary to use a
locally-compiled version of `rustc`. This is no longer the case and the
documentation should reflect this.
This new enum entry was introduced in https://reviews.llvm.org/D122268,
and if I'm reading correctly there's no case where we'd ever encounter
it in our uses of LLVM. To preserve the ability to compile this file
with -Werror -Wswitch we add an explicit case for this entry.
this is a breaking change in order to fix a soundness bug.
Before this PR we only checked whether the repeat element type had an `impl Copy`, but not whether that impl also had the appropriate lifetimes. E.g. if the impl was for `YourType<'static>` and not a general `'a`, then copying any type other than a `'static` one should have been rejected, but wasn't.
Andrew Brown [Fri, 29 Apr 2022 17:32:34 +0000 (10:32 -0700)]
Remove unnecessary environment variable in cf-protection documentation
Before merging the `cf-protection` flag, it was necessary to use a
locally-compiled version of `rustc`. This is no longer the case and the
documentation should reflect this.
Auto merge of #96468 - davidtwco:diagnostic-translation-subdiagnostic, r=oli-obk
macros: subdiagnostic derive
Add a new macro, `#[derive(SessionSubdiagnostic)]`, which can be applied to structs that represent subdiagnostics, such as labels, notes, helps or suggestions.
`#[derive(SessionSubdiagnostic)]` can be used with the existing `#[derive(SessionDiagnostic)]`. All diagnostics implemented using either derive are translatable, and this new derive should make it easier to port existing diagnostics to using these derives.
For example, consider the following subdiagnostic types...
Auto merge of #96548 - Dylan-DPC:rollup-m3xkqxg, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #96477 (Update data layout string for wasm64-unknown-unknown)
- #96481 (HashMap doc: Don't use monospace font for 'Entry Api')
- #96492 (Revert "Re-export core::ffi types from std::ffi")
- #96516 (Revert diagnostic duplication and accidental stabilization)
- #96523 (Add ``@feat.00`` symbol to symbols.o for COFF)
Fixes https://github.com/rust-lang/rust/issues/96435 , a regression
in crates doing `use std::ffi::*;` and `use std::os::raw::*;`.
We can re-add this re-export once the `core::ffi` types
are stable, and thus the `std::os::raw` types can become re-exports as
well, which will avoid the conflict. (Type aliases to the same type
still conflict, but re-exports of the same type don't.)
David Wood [Wed, 27 Apr 2022 04:43:36 +0000 (05:43 +0100)]
macros: allow setting applicability in attribute
In the initial implementation of the `SessionSubdiagnostic`, the
`Applicability` of a suggestion can be set both as a field and as part
of the attribute, this commit adds the same support to the original
`SessionDiagnostic` derive.
David Wood [Tue, 26 Apr 2022 05:17:33 +0000 (06:17 +0100)]
errors: `span_suggestion` takes `impl ToString`
Change `span_suggestion` (and variants) to take `impl ToString` rather
than `String` for the suggested code, as this simplifies the
requirements on the diagnostic derive.
Auto merge of #96393 - joboet:pthread_parker, r=thomcc
std: directly use pthread in UNIX parker implementation
`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore we should use the `pthread` synchronization primitives directly. Also, we can avoid allocating the mutex and condition variable because the `Parker` struct is being placed in an `Arc` anyways.
This basically is just a copy of the current `Mutex` and `Condvar` code, which will however be removed (again, see #93740). An alternative implementation could be to use dedicated private `OsMutex` and `OsCondvar` types, but all the other platforms supported by std actually have their own thread parking primitives.
I used `Pin` to guarantee a stable address for the `Parker` struct, while the current implementation does not, rather using extra unsafe declaration. Since the thread struct is shared anyways, I assumed this would not add too much clutter while being clearer.
Auto merge of #96528 - Dylan-DPC:rollup-iedbjli, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #95312 (Ensure that `'_` and GAT yields errors)
- #96405 (Migrate ambiguous plus diagnostic to the new derive macro)
- #96409 (Recover suggestions to introduce named lifetime under NLL)
- #96433 (rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`)
- #96480 (Fixed grammatical error in example comment)
Rollup merge of #96433 - petrochenkov:delim, r=nnethercote
rustc_ast: Harmonize delimiter naming with `proc_macro::Delimiter`
Compiler cannot reuse `proc_macro::Delimiter` directly due to extra impls, but can at least use the same naming.
After this PR the only difference between these two enums is that `proc_macro::Delimiter::None` is turned into `token::Delimiter::Invisible`.
It's my mistake that the invisible delimiter is called `None` on stable, during the stabilization I audited the naming and wrote the docs, but missed the fact that the `None` naming gives a wrong and confusing impression about what this thing is.
cc https://github.com/rust-lang/rust/pull/96421
r? ``@nnethercote``
This new enum entry was introduced in https://reviews.llvm.org/D122268,
and if I'm reading correctly there's no case where we'd ever encounter
it in our uses of LLVM. To preserve the ability to compile this file
with -Werror -Wswitch we add an explicit case for this entry.
GCC was bumped to allow building the new LLVM version. The changes in building LLVM were done to speed up the build a bit by ignoring unused parts and to turn off parts that were problematic to compile even with the bumped GCC.
Auto merge of #95976 - b-naber:valtree-constval-conversion, r=oli-obk
Implement Valtree to ConstValue conversion
Once we start to use `ValTree`s in the type system we will need to be able to convert them into `ConstValue` instances, which we want to continue to use after MIR construction.
Auto merge of #95904 - paolobarbolini:vecdeque-specextend, r=the8472
Add VecDeque::extend from vec::IntoIter and slice::Iter specializations
Inspired from the [`Vec` `SpecExtend` implementation](https://github.com/rust-lang/rust/blob/027a232755fa9728e9699337267f6675dfd0a8ba/library/alloc/src/vec/spec_extend.rs), but without the specialization for `TrustedLen` which I'll look into in the future.
Should help #95632 and https://github.com/KillingSpark/zstd-rs/pull/17
## Benchmarks
Before
```
test vec_deque::bench_extend_bytes ... bench: 862 ns/iter (+/- 10)
test vec_deque::bench_extend_vec ... bench: 883 ns/iter (+/- 19)
```
After
```
test vec_deque::bench_extend_bytes ... bench: 8 ns/iter (+/- 0)
test vec_deque::bench_extend_vec ... bench: 24 ns/iter (+/- 1)
Auto merge of #96085 - jsgf:deny-unused-deps, r=compiler-errors
Make sure `-Dunused-crate-dependencies --json unused-externs` makes rustc exit with error status
This PR:
- fixes compiletest to understand unused extern notifications
- adds tests for `--json unused-externs`
- makes sure that deny-level unused externs notifications are treated as compile errors
- refactors the `emit_unused_externs` callstack to plumb through the level as an enum as a string, and adds `Level::is_error`
Update: adds `--json unused-externs-silent` with the original behaviour since Cargo needs it. Should address `@est31's` concerns.
Auto merge of #96495 - Dylan-DPC:rollup-9lm4tpp, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #96377 (make `fn() -> _ { .. }` suggestion MachineApplicable)
- #96397 (Make EncodeWide implement FusedIterator)
- #96421 (Less `NoDelim`)
- #96432 (not need `Option` for `dbg_scope`)
- #96466 (Better error messages when collecting into `[T; n]`)
- #96471 (replace let else with `?`)
- #96483 (Add missing `target_feature` to the list of well known cfg names)
Rollup merge of #96483 - Urgau:check-cfg-target_feature, r=petrochenkov
Add missing `target_feature` to the list of well known cfg names
This PR adds the missing `target_feature` cfg name to the list of well known cfg names.
It was notice missing in https://github.com/rust-lang/rust/issues/96472 thanks to `@bjorn3,` the reason being that `--check-cfg=names()` automatically inherit the names passed by `--cfg` (or internal to `rustc`) and is seems that the vast majority of targets have at least one target feature leading to `target_feature` being a well known name in most target but it should always be a well known name so this PR add it unconditionally to list.
Rollup merge of #96432 - SparrowLii:dbg_scope, r=davidtwco
not need `Option` for `dbg_scope`
This PR fixes a few FIXME about not using `Option` in `dbg_scope` field of `DebugScope`, during `create_function_debug_context` func in codegen parts.
Added a `BitSet<SourceScope>` parameter to `make_mir_scope` to indicate whether the `DebugScope` has been instantiated.
cc ````@eddyb````
Rollup merge of #96421 - nnethercote:less-NoDelim, r=petrochenkov
Less `NoDelim`
Currently there are several places where `NoDelim` (which really means "implicit delimiter" or "invisible delimiter") is used to mean "no delimiter". The name `NoDelim` is a bit misleading, and may be a cause.
This PR changes these places, e.g. by changing a `DelimToken` to `Option<DelimToken>` and then using `None` to mean "no delimiter". As a result, the *only* place where `NoDelim` values are now produced is within:
- `Delimiter::to_internal()`, when converting from `Delimiter::None`.
- `FlattenNonterminals::process_token()`, when converting `TokenKind::Interpolated`.
Rollup merge of #96397 - AronParker:issue-96368-fix, r=dtolnay
Make EncodeWide implement FusedIterator
[`EncodeUtf16`](https://doc.rust-lang.org/std/str/struct.EncodeUtf16.html) and [`EncodeWide`](https://doc.rust-lang.org/std/os/windows/ffi/struct.EncodeWide.html) currently serve similar purposes: They convert from UTF-8 to UTF-16 and WTF-8 to WTF-16, respectively. `EncodeUtf16` wraps a &str, whereas `EncodeWide` wraps an &OsStr.
When Iteration has concluded, these iterators wrap an empty slice, which will forever yield `None` values. Hence, `EncodeUtf16` rightfully implements `FusedIterator`. However, `EncodeWide` in contrast does not, even though it serves an almost identical purpose.
This PR attempts to fix that issue. I consider this change minor and non-controversial, hence why I have not added a RFC/FCP. Please let me know if the stability attribute is wrong or contains a wrong version number. Thanks in advance.
Rollup merge of #96377 - compiler-errors:infer-rustfix, r=petrochenkov
make `fn() -> _ { .. }` suggestion MachineApplicable
This might not be valid, but it would be nice to promote this to `MachineApplicable` so people can use rustfix here.
Also de65fcf009d07019689cfad7f327667e390a325d is to [restore the suggestion for `issue-77179.rs`](https://github.com/rust-lang/rust/commit/de65fcf009d07019689cfad7f327667e390a325d#diff-12e43fb5d6d12ec7cb5c6b48204a18d113cf5de0e12eb71a358b639bd9aadaf0R8). (though in this case, the code in that issue still doesn't compile, so it's not marked with rustfix).
Auto merge of #91557 - cjgillot:ast-lifetimes-named, r=petrochenkov
Perform lifetime resolution on the AST for lowering
Lifetime resolution is currently implemented several times. Once during lowering in order to introduce in-band lifetimes, and once in the resolve_lifetimes query. However, due to the global nature of lifetime resolution and how it interferes with hygiene, it is better suited on the AST.
This PR implements a first draft of lifetime resolution on the AST. For now, we specifically target named lifetimes and everything we need to remove lifetime resolution from lowering. Some diagnostics have already been ported, and sometimes made more precise using available hygiene information. Follow-up PRs will address in particular the resolution of anonymous lifetimes on the AST.
We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics`, which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes.
Fixes https://github.com/rust-lang/rust/issues/96435 , a regression
in crates doing `use std::ffi::*;` and `use std::os::raw::*;`.
We can re-add this re-export once the `core::ffi` types
are stable, and thus the `std::os::raw` types can become re-exports as
well, which will avoid the conflict. (Type aliases to the same type
still conflict, but re-exports of the same type don't.)
projects / rust.git / log