Rollup of 12 pull requests
Successful merges:
- #75115 (`#[deny(unsafe_op_in_unsafe_fn)]` in sys/cloudabi)
- #76614 (change the order of type arguments on ControlFlow)
- #77610 (revise Hermit's mutex interface to support the behaviour of StaticMutex)
- #77830 (Simplify query proc-macros)
- #77930 (Do not ICE with TraitPredicates containing [type error])
- #78069 (Fix const core::panic!(non_literal_str).)
- #78072 (Cleanup constant matching in exhaustiveness checking)
- #78119 (Throw core::panic!("message") as &str instead of String.)
- #78191 (Introduce a temporary for discriminant value in MatchBranchSimplification)
- #78272 (const_evaluatable_checked: deal with unused nodes + div)
- #78318 (TyCtxt: generate single impl block with `slice_interners` macro)
- #78327 (resolve: Relax macro resolution consistency check to account for any errors)
Failed merges:
r? `@ghost`
resolve: Relax macro resolution consistency check to account for any errors
The check was previously omitted only when ambiguity errors or `Res::Err` were encountered, but the "macro-expanded `extern crate` items cannot shadow..." error (at least) can cause same inconsistencies as well.
Fixes https://github.com/rust-lang/rust/issues/78325
Introduce a temporary for discriminant value in MatchBranchSimplification
The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.
Evaluate it once at original position, and store the result in a new temporary.
Follow up on #78151. The optimization remains disabled by default.
Closes#78239.
Cleanup constant matching in exhaustiveness checking
This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work.
I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately.
I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior.
EDIT: I accidentally fixed#78071
Fix const core::panic!(non_literal_str).
Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.
This fixes the issue mentioned here: https://github.com/rust-lang/rust/issues/51999#issuecomment-687604248
r? `@RalfJung`
`@rustbot` modify labels: +A-const-eval
Simplify query proc-macros
The query code generation is split between proc-macros and regular macros in `rustc_middle::ty::query`.
This PR removes unused capabilities of the proc-macros, and tend to use regular macros for the logic.
change the order of type arguments on ControlFlow
This allows ControlFlow<BreakType> which is much more ergonomic for common iterator combinator use cases.
Addresses one component of #75744
Unconditionally capture tokens for attributes.
This allows us to avoid synthesizing tokens in `prepend_attr`, since we
have the original tokens available.
We still need to synthesize tokens when expanding `cfg_attr`,
but this is an unavoidable consequence of the syntax of `cfg_attr` -
the user does not supply the `#` and `[]` tokens that a `cfg_attr`
expands to.
This is based on PR https://github.com/rust-lang/rust/pull/77250 - this PR exposes a bug in the current `collect_tokens` implementation, which is fixed by the rewrite.
Fixes#75982
The direct parent of a module may not be a module
(e.g. `const _: () = { #[path = "foo.rs"] mod foo; };`).
To find the parent of a module for purposes of resolution, we need to
walk up the tree until we hit a module or a crate root.
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.
```rust
trait Foo {
#[allow(unused_attributes)] #[inline] fn first();
#[inline] #[allow(unused_attributes)] fn second();
}
```
However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).
Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.
This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:
* The `HasAttr` impl for `StmtKind` now returns attributes for
`StmtKind::Item`, treating it just like every other `StmtKind`
variant. The only place relying on the old behavior was macro
which has been updated to explicitly ignore attributes on item
statements. This allows the `unused_doc_comments` lint to fire for
item statements.
* The `early` and `late` lint visitors now activate lint attributes when
invoking the callback for `Stmt`. This ensures that a lint
attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
sibiling attributes on an item statement.
For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
Make codegen coverage_context optional, and check
Addresses Issue #78286
Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).
Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.
move `visit_predicate` into `TypeVisitor`
Seems easier than dealing with `PredicateVisitor` for me which I needed for object safety checks for `PredicateAtom::ConstEvaluatable`. Is there a reason I am missing for this split?
r? @matthewjasper
improve const infer error
For type inference we probably have to be careful about subtyping and stuff but considering that subtyping shouldn't be relevant for constants I don't really see a reason why we may not want to reuse the const origin here.
r? `@varkor`
Revert "Allow dynamic linking for iOS/tvOS targets."
This reverts PR #73516.
On macOS I compile static libs for iOS, automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile), which has worked smoothly for the past 2 years. However, upon updating to Rust 1.46.0, I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above.
For most projects tested, apps now immediately crash with a message like this:
```
dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib
Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example
Reason: image not found
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib
```
This can be reproduced by using cargo-mobile to generate a winit example project, and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`).
In our projects that depend on DisplayLink, the build instead fails with a linker error:
```
= note: Undefined symbols for architecture arm64:
"_CACurrentMediaTime", referenced from:
display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
ld: symbol(s) not found for architecture arm64
```
After reverting the change to enable dynamic linking on iOS, everything works the same as it did on Rust 1.45.2 for me.
In the future, would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production, so I'd gladly provide testing.
cc @aspenluxxxy
Addresses Issue #78286
Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).
Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.
passes: `check_attr` on more targets
This PR modifies `check_attr` so that:
- Enum variants are now checked (some attributes would not have been prohibited on variants previously).
- `check_expr_attributes` and `check_stmt_attributes` are removed as `check_attributes` can perform the same checks. This means that codegen attribute errors aren't shown if there are other errors first (e.g. from other attributes, as shown in `src/test/ui/macros/issue-68060.rs` changes below).
The validation was introduced in 3a63bf02998f7b5e040a4b87e049d03ddd144f74
without strict validation of functions, e. g. all function types were
allowed.
Now the validation only allows `const fn`s.
