CFI: Fix error compiling core with LLVM CFI enabled
Fix#90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
add aarch64-unknown-teeos target
TEEOS is a mini os run in TrustZone, for trusted/security apps. The libc of TEEOS is a part of musl. The kernel of TEEOS is micro kernel.
This MR is to add a target for teeos.
MRs for libc and rust-std are in progress.
Compiler team MCP: [MCP](https://github.com/rust-lang/compiler-team/issues/652)
Map RPIT duplicated lifetimes back to fn captured lifetimes
Use the [`lifetime_mapping`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping) to map an RPIT's captured lifetimes back to the early- or late-bound lifetimes from its parent function. We may be going thru several layers of mapping, since opaques can be nested, so we introduce `TyCtxt::map_rpit_lifetime_to_fn_lifetime` to loop through several opaques worth of mapping, and handle turning it into a `ty::Region` as well.
We can then use this instead of the identity substs for RPITs in `check_opaque_meets_bounds` to address #114285.
We can then also use `map_rpit_lifetime_to_fn_lifetime` to properly install bidirectional-outlives predicates for both RPITs and RPITITs. This addresses #114601.
I based this on #114574, but I don't actually know how much of that PR we still need, so some code may be redundant now... 🤷
---
Fixes#114597Fixes#114579Fixes#114285
Also fixes#114601, since it turns out we had other bugs with RPITITs and their duplicated lifetime params 😅.
Supersedes #114574
r? `@oli-obk`
Structurally normalize weak and inherent in new solver
It seems pretty obvious to me that we should be normalizing weak and inherent aliases too, since they can always be normalized. This PR still leaves open the question of what to do with opaques, though 💀
**Also**, we need to structurally resolve the target of a coercion, for the UI test to work.
r? `@lcnr`
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
Warn when #[macro_export] is applied on decl macros
The existing code checks if `#[macro_export]` is being applied to an item other than a macro, and warns in that case, but fails to take into account macros 2.0/decl macros, despite the attribute having no effect on these macros.
This PR adds a special case for decl macros with the aforementioned attribute, so that the warning is a bit more precise. Instead of just saying "this attribute has no effect", hint towards the fact that decl macros get exported and resolved like regular items.
It also removes a `#[macro_export]` attribute which was applied on one of `core`'s decl macros.
- core: Remove #[macro_export] from `debug_assert_matches`
- check_attrs: Warn when #[macro_export] is used on macros 2.0
Fix#90546 by filtering out global value function pointer types from the
type tests, and adding the LowerTypeTests pass to the rustc LTO
optimization pipelines.
The compiler should emit a more specific error when the `#[macro_export]`
attribute is present on a decl macro, instead of silently ignoring it.
This commit adds the required error message in rustc_passes/messages.ftl,
as well as a note. A new variant is added to the `errors::MacroExport`
enum, specifically for the case where the attribute is added to a macro
2.0.
Rollup of 9 pull requests
Successful merges:
- #113568 (Fix spurious test failure with `panic=abort`)
- #114196 (Bubble up nested goals from equation in `predicates_for_object_candidate`)
- #114485 (Add trait decls to SMIR)
- #114495 (Set max_atomic_width for AVR to 16)
- #114496 (Set max_atomic_width for sparc-unknown-linux-gnu to 32)
- #114510 (llvm-wrapper: adapt for LLVM API changes)
- #114562 (stabilize abi_thiscall)
- #114570 ([miri][typo] Fix a typo in a vector_block comment.)
- #114573 (CI: do not hide error logs in a group)
r? `@ghost`
`@rustbot` modify labels: rollup
Bubble up nested goals from equation in `predicates_for_object_candidate`
This used to be needed for https://github.com/rust-lang/rust/pull/114036#discussion_r1273987510, but since it's no longer, I'm opening this as a separate PR. This also fixes one ICEing UI test: (`tests/ui/unboxed-closures/issue-53448.rs`)
r? `@lcnr`
Make `unconditional_recursion` warning detect recursive drops
Closes#55388
Also closes#50049 unless we want to keep it for the second example which this PR does not solve, but I think it is better to track that work in #57965.
r? `@oli-obk` since you are the mentor for #55388
Unresolved questions:
- [x] There are two false positives that must be fixed before merging (see diff). I suspect the best way to solve them is to perform analysis after drop elaboration instead of before, as now, but I have not explored that any further yet. Could that be an option? **Answer:** Yes, that solved the problem.
`@rustbot` label +T-compiler +C-enhancement +A-lint
Add a new `compare_bytes` intrinsic instead of calling `memcmp` directly
As discussed in #113435, this lets the backends be the place that can have the "don't call the function if n == 0" logic, if it's needed for the target. (I didn't actually *add* those checks, though, since as I understood it we didn't actually need them on known targets?)
Doing this also let me make it `const` (unstable), which I don't think `extern "C" fn memcmp` can be.
cc `@RalfJung` `@Amanieu`
Remove FIXME about NLL diagnostic that is already improved
The FIXME was added in #46984 when the diagnostic message looked like this:
// FIXME(#46983): error message should be better
&s.0 //~ ERROR free region `` does not outlive free region `'static`
The message was improved in #90667 and now looks like this:
&s.0 //~ ERROR lifetime may not live long enough
but the FIXME was not removed. The issue #46983 about that diagnostics should be improved has been closed. We can remove the FIXME now.
(This PR was made for #44366.)
The FIXME was added in 46984 when the diagnostic message looked like
this:
// FIXME(#46983): error message should be better
&s.0 //~ ERROR free region `` does not outlive free region `'static`
The message was improved in 90667 and now looks like this:
&s.0 //~ ERROR lifetime may not live long enough
but the FIXME was not removed. The issue 46983 about that diagnostics
should be improved has been closed. We can remove the FIXME now.
Avoid invalid NaN lint machine-applicable suggestion in const context
This PR removes the machine-applicable suggestion in const context for the `invalid_nan_comparision` lint ~~and replace it with a simple help~~.
Fixes https://github.com/rust-lang/rust/issues/114471
Rename tests/ui/issues/issue-100605.rs to ../type/option-ref-advice.rs
The test is a regression test for a [bug ](https://github.com/rust-lang/rust/issues/100605) where the compiler gave bad advice for an `Option<&String>`. Rename the file appropriately.
Part of #73494
Resolve visibility paths as modules not as types.
Asking for a resolution with `opt_ns = Some(TypeNS)` allows path resolution to look for type-relative paths, leaving unresolved segments behind. However, for visibility paths we really need to look for a module, so we need to pass `opt_ns = None`.
Fixes https://github.com/rust-lang/rust/issues/109146
r? `@petrochenkov`
Convert builtin "global" late lints to run per module
The compiler currently has 4 non-incremental lints:
1. `clashing_extern_declarations`;
2. `missing_debug_implementations`;
3. ~`unnameable_test_items`;~ changed by https://github.com/rust-lang/rust/pull/114414
4. `missing_docs`.
Non-incremental lints get reexecuted for each compilation, which is slow. Moreover, those lints are allow-by-default, so run for nothing most of the time. This PR attempts to make them more incremental-friendly.
`clashing_extern_declarations` is moved to a standalone query.
`missing_debug_implementation` can use `non_blanket_impls_for_ty` instead of recomputing it.
`missing_docs` is harder as it needs to track if there is a `doc(hidden)` module surrounding. I hack around this using the lint level engine. That's easy to implement and allows to re-enable the lint for a re-exported module, while a more proper solution would reuse the same device as `unnameable_test_items`.
update overflow handling in the new trait solver
implements https://hackmd.io/QY0dfEOgSNWwU4oiGnVRLw?view. I want to clean up this doc and add it to the rustc-dev-guide, but I think this PR is ready for merge as is, even without the dev-guide entry.
r? `@compiler-errors`
Add separate feature gate for async fn track caller
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes#110009
