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.
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.
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)
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.
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)
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.
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(...).
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.
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)
```
Rollup merge of #88996 - Aaron1011:trailing-macro-semi, r=petrochenkov
Fix linting when trailing macro expands to a trailing semi
When a macro is used in the trailing expression position of a block
(e.g. `fn foo() { my_macro!() }`), we currently parse it as an
expression, rather than a statement. As a result, we ended up
using the `NodeId` of the containing statement as our `lint_node_id`,
even though we don't normally do this for macro calls.
If such a macro expands to an expression with a `#[cfg]` attribute,
then the trailing statement can get removed entirely. This lead to
an ICE, since we were usng the `NodeId` of the expression to emit
a lint.
Ths commit makes us skip updating `lint_node_id` when handling
a macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.
Rollup merge of #87960 - hkmatsumoto:suggest-inexisting-field-for-unmentioned-field, r=estebank
Suggest replacing an inexisting field for an unmentioned field
Fix #87938
This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
Bar { alpha: u8, bravo: u8, charlie: u8 },
}
fn foo(foo: Foo) {
match foo {
Foo::Bar {
alpha,
beta, // `bravo` miswritten as `beta` here.
charlie,
} => todo!(),
}
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
--> src/lib.rs:9:13
|
9 | beta, // `bravo` miswritten as `beta` here.
| ^^^^
| |
| variant `Foo::Bar` does not have this field
| help: `Foo::Bar` has a field named `bravo`: `bravo`
```
Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.
Auto merge of #89028 - Aaron1011:coercion-cause, r=nagisa
Propagate coercion cause into `try_coerce`
Currently, `coerce_inner` discards its `ObligationCause`
when calling `try_coerce`. This interfers with other
diagnostc improvements I'm working on, since we will lose
the original span by the time the actual coercion occurs.
Additionally, we now use the span of the trailing expression
(rather than the span of the entire function) when performing
a coercion in `check_return_expr`. This currently has no visible
effect on any of the unit tests, but will unblock future
diagnostic improvements.
Auto merge of #88968 - tmiasko:start-block-no-predecessors, r=davidtwco
Start block is not allowed to have basic block predecessors
* The MIR validator is extended to detect potential violations.
* The start block has no predecessors after building MIR, so no changes are required there.
* The SimplifyCfg could previously violate this requirement when collapsing goto chains, so transformation is disabled for the start block, which also substantially simplifies the implementation.
* The LLVM function entry block also must not have basic block predecessors. Previously, to ensure that code generation had to perform necessary adjustments. This now became unnecessary.
The motivation behind the change is to align with analogous requirement in LLVM, and to avoid potential latent bugs like the one reported in #88043.
Auto merge of #89000 - Mark-Simulacrum:no-new-lrc, r=petrochenkov
Reuse existing shared Lrc for MatchImpl parent
This is a small performance win for the hot path, which helps to address this regression: https://github.com/rust-lang/rust/pull/87244#issuecomment-883635813.
Auto merge of #88994 - Aaron1011:intercrate-caching, r=jackh726
Disable the evaluation cache when in intercrate mode
It's possible to use the same `InferCtxt` with both
an intercrate and non-intercrate `SelectionContext`. However,
the local (inferctxt) evaluation cache is not aware of this
distinction, so this kind of `InferCtxt` re-use will pollute
the cache wth bad results.
This commit avoids the issue by disabling the evaluation cache
entirely during intercrate mode.
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.
Auto merge of #88650 - sapessi:issue-77175-fix, r=estebank
Skip single use lifetime lint for generated opaque types
Fix: #77175
The opaque type generated by the desugaring process of an async function uses the lifetimes defined by the originating function. The DefId for the lifetimes in the opaque type are different from the ones in the originating async function - as they should be, as far as I understand, and could therefore be considered a single use lifetimes, this causes the single_use_lifetimes lint to fail compilation if explicitly denied. This fix skips the lint for lifetimes used only once in generated opaque types for an async function that are declared in the parent async function definition.
More info in the comments on the original issue: 1 and 2
Auto merge of #88988 - Mark-Simulacrum:avoid-into-ok, r=nagisa
Avoid codegen for Result::into_ok in lang_start
This extra codegen seems to be the cause for the regressions in max-rss on #86034. While LLVM will certainly optimize the dead code away, avoiding it's generation in the first place seems good, particularly when it is so simple.
#86034 produced this [diff](https://gist.github.com/Mark-Simulacrum/95c7599883093af3b960c35ffadf4dab#file-86034-diff) for a simple `fn main() {}`. With this PR, that diff [becomes limited to just a few extra IR instructions](https://gist.github.com/Mark-Simulacrum/95c7599883093af3b960c35ffadf4dab#file-88988-from-pre-diff) -- no extra functions.
Note that these are pre-optimization; LLVM surely will eliminate this during optimization. However, that optimization can end up generating more work and bump memory usage, and this eliminates that.
Auto merge of #88980 - tmiasko:instrument-debug, r=oli-obk
Use explicit log level in tracing instrument macro
Specify a log level in tracing instrument macro explicitly.
Additionally reduce the used log level from a default info level to a
debug level (all of those appear to be developer oriented logs, so there
should be no need to include them in release builds).
Tomasz Miąsko [Wed, 15 Sep 2021 00:00:00 +0000 (00:00 +0000)]
Do not collapse goto chains beginning with the start block
If any block on a goto chain has more than one predecessor, then the new
start block would have basic block predecessors.
Skip the transformation for the start block altogether, to avoid
violating the new invariant that the start block does not have any basic
block predecessors.
Auto merge of #89047 - GuillaumeGomez:rollup-29gmr02, r=GuillaumeGomez
Rollup of 10 pull requests
Successful merges:
- #86422 (Emit clearer diagnostics for parens around `for` loop heads)
- #87460 (Point to closure when emitting 'cannot move out' for captured variable)
- #87566 (Recover invalid assoc type bounds using `==`)
- #88666 (Improve build command for compiler docs)
- #88899 (Do not issue E0071 if a type error has already been reported)
- #88949 (Fix handling of `hir::GenericArg::Infer` in `wrong_number_of_generic_args.rs`)
- #88953 (Add chown functions to std::os::unix::fs to change the owner and group of files)
- #88954 (Allow `panic!("{}", computed_str)` in const fn.)
- #88964 (Add rustdoc version into the help popup)
- #89012 (Suggest removing `#![feature]` for library features that have been stabilized)
Rollup merge of #89012 - vishadGoyal:issue-88802-fix, r=jyn514
Suggest removing `#![feature]` for library features that have been stabilized
Issue: https://github.com/rust-lang/rust/issues/88802
Delayed the check if #![feature] has been used to enable lib features in a non-nightly build to occur after TyCtxt has been constructed.
Rollup merge of #88964 - GuillaumeGomez:version-help, r=Nemo157
Add rustdoc version into the help popup
After a discussion with a rustdoc user about a specific behaviour, we realized we were not talking about the same version. To add on top of it, it was actually not that simple to find out the version since it was hosted documentation.
So to simplify things, I added the version into the help popup:
Rollup merge of #88954 - nbdd0121:panic3, r=oli-obk
Allow `panic!("{}", computed_str)` in const fn.
Special-case `panic!("{}", arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!("{}", arg))` in runtime.
This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999.
Rollup merge of #88953 - joshtriplett:chown, r=dtolnay
Add chown functions to std::os::unix::fs to change the owner and group of files
This is a straightforward wrapper that uses the existing helpers for C
string handling and errno handling.
Having this available is convenient for UNIX utility programs written in
Rust, and avoids having to call unsafe functions like `libc::chown`
directly and handle errors manually, in a program that may otherwise be
entirely safe code.
In addition, these functions provide a more Rustic interface by
accepting appropriate traits and using `None` rather than `-1`.
Rollup merge of #88949 - FabianWolff:issue-87563, r=estebank
Fix handling of `hir::GenericArg::Infer` in `wrong_number_of_generic_args.rs`
Fixes #87563. More precisely, I have fixed the "index out of bounds" error, which is what #87563 is about. The example given there still ICEs due to running into this `todo!()`, but I'd say that this is a separate issue:
https://github.com/rust-lang/rust/blob/c3c0f80d6081092faff801542dd82f0e2420152b/compiler/rustc_typeck/src/astconv/mod.rs#L460-L463
Rollup merge of #88899 - FabianWolff:issue-88844, r=matthewjasper
Do not issue E0071 if a type error has already been reported
Fixes #88844. A suggested fix is already included in the error message for E0412, so with my changes, E0071 is simply not emitted anymore if the type in question is a "type error". This makes sense, I think, because we cannot confidently state that something is "not a struct" if we couldn't resolve it properly; and it's unnecessary to pollute the output with this additional error message, as it is a direct consequence of the former error.
I have also addressed the issue mentioned in https://github.com/rust-lang/rust/issues/88844#issuecomment-917324856 by changing the fixed example in the documentation to more closely match the erroneous code example.
Rollup merge of #87460 - FabianWolff:issue-87456, r=Aaron1011
Point to closure when emitting 'cannot move out' for captured variable
Attempts to fix #87456. The error message now points to the capturing closure, but I was not able to explain _why_ the closure implements `Fn` or `FnMut` (`TypeckResults::closure_kind_origins` did not contain anything for the closure in question).
Auto merge of #88945 - Aaron1011:no-projection-completion, r=wesleywiser,jackh726
Remove concept of 'completion' from the projection cache
Fixes #88910
When we initially store a `NormalizedTy` in the projection cache,
we discard all obligations that we can (while ensuring that we
don't cause any issues with incremental compilation).
Marking a projection cache entry as 'completed' discards all
obligations associated with it. This can only cause problems,
since any obligations stored in the cache are there for a reason
(e.g. they evaluate to `EvaluatedToOkModuloRegions`).
This commit removes `complete` and `complete_normalized` entirely.
Auto merge of #89037 - JohnTitor:rollup-rd9btbs, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #86382 (Make diagnostics clearer for `?` operators)
- #87529 (Fix ICE in `improper_ctypes_definitions` lint with all-ZST transparent types)
- #88339 (Add TcpListener::into_incoming and IntoIncoming)
- #88735 (Don't lint about missing code examples in derived traits)
- #88751 (Couple of changes to FileSearch and SearchPath)
- #88883 (Move some tests to more reasonable directories - 7)
- #88887 (Const Deref)
- #88911 (Improve error message for type mismatch in generator arguments)
- #89014 (PassWrapper: handle separate Module*SanitizerPass)
- #89033 (Set the library path in sysroot-crates-are-unstable)
Rollup merge of #89033 - cuviper:sysroot-lib-path, r=Mark-Simulacrum
Set the library path in sysroot-crates-are-unstable
Most of the `run-make-fulldeps` tests use a make-driven rustc command
that includes `HOST_RPATH_DIR` in the library path, but this particular
test runs from python instead. When the toolchain is built without
`rpath` enabled, we need that library path in the environment so it can
find its own libraries.
Rollup merge of #89014 - durin42:llvm-14-module-pass-manager, r=nikic
PassWrapper: handle separate Module*SanitizerPass
Change ab41eef9aca3 in LLVM split MemorySanitizerPass into
MemorySanitizerPass for functions and ModuleMemorySanitizerPass for
modules. There's a related change for ThreadSanitizerPass, and in here
since we're using a ModulePassManager I only add the module flavor of
the pass on LLVM 14.
Rollup merge of #88911 - FabianWolff:issue-88653, r=petrochenkov
Improve error message for type mismatch in generator arguments
Fixes #88653. The code example given there is invalid because the `Generator` trait (unlike the `Fn` traits) does not take the generator arguments in tupled-up form (because there can only be one argument, from my understanding). Hence, the type error in the example in #88653 is correct, because the given generator takes a `bool` argument, whereas the function's return type talks about a generator with a `(bool,)` argument.
The error message is both confusing and wrong, though: It is wrong because it displays the wrong "expected signature", and it is confusing because both the "expected" and "found" notes point at the same span. With my changes, I get the following, more helpful output:
```
error[E0631]: type mismatch in generator arguments
--> test.rs:5:22
|
5 | fn foo(bar: bool) -> impl Generator<(bool,)> {
| ^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `fn((bool,)) -> _`
6 | |bar| {
| ----- found signature of `fn(bool) -> _`
```
Rollup merge of #88751 - bjorn3:move_filesearch, r=oli-obk
Couple of changes to FileSearch and SearchPath
* Turn a couple of regular comments into doc comments
* Move `get_tools_search_paths` from `FileSearch` to `Session`
* Use Lrc instead of Option to avoid duplication of a `SearchPath`
Rollup merge of #88735 - hnj2:patch-1, r=GuillaumeGomez
Don't lint about missing code examples in derived traits
When the `missing_doc_code_examples` lint is performed it also requires that derived Trait implementations have a code example for each member etc., which causes undesirable behavior.
# Examples
With `missing_doc_code_examples` enable we are not able to use the `Clone` derive macro due to the generated code not being documented:
```rust
#[deny(rustdoc::missing_doc_code_examples)]
/// docs
/// ```
/// let s = SomeStruct;
/// ```
#[derive(Clone)]
pub struct SomeStruct;
```
yields:
```
Documenting testt v0.1.0 (<redacted>)
error: missing code example in this documentation
--> src/lib.rs:7:10
|
7 | #[derive(Clone)]
| ^^^^^
|
note: the lint level is defined here
--> src/lib.rs:1:8
|
1 | #[deny(rustdoc::missing_doc_code_examples)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: missing code example in this documentation
--> src/lib.rs:7:10
|
7 | #[derive(Clone)]
| ^^^^^
error: could not document `testt`
Caused by:
process didn't exit successfully: `rustdoc ...
```
Rollup merge of #88339 - piegamesde:master, r=joshtriplett
Add TcpListener::into_incoming and IntoIncoming
The `incoming` method is really useful, however for some use cases the borrow
this introduces is needlessly restricting. Thus, an owned variant is added.
Rollup merge of #87529 - FabianWolff:issue-87496, r=nikomatsakis
Fix ICE in `improper_ctypes_definitions` lint with all-ZST transparent types
Fixes #87496. There is also another function in the same file that looks fishy, but I haven't been able to produce an ICE there, and in any case, it's not related to #87496:
https://github.com/rust-lang/rust/blob/fd853c00e255559255885aadff9e93a1760c8728/compiler/rustc_lint/src/types.rs#L720-L734
projects / rust.git / log