Commit Graph

31091 Commits

Author SHA1 Message Date
Matthias Krüger
f6a04f693b
Rollup merge of #119141 - celinval:smir-instance-args, r=compiler-errors
Add method to get instance instantiation arguments

Add a method to get the instance instantiation arguments, and include that information in the instance debug.
2023-12-20 21:18:59 +01:00
Celina G. Val
e0a4693294 Add method to get instance instantiation arguments 2023-12-20 11:07:06 -08:00
Celina G. Val
7ab38b80eb Add ItemKind::Ctor to stable mir 2023-12-20 10:53:40 -08:00
Celina G. Val
a8556da672 Fix crash for CrateItem::kind() with constructors
Change how we classify item kind for DefKind::Ctor
2023-12-20 10:50:40 -08:00
bors
92ad4b433a Auto merge of #119166 - GuillaumeGomez:rollup-qfgj76w, r=GuillaumeGomez
Rollup of 3 pull requests

Successful merges:

 - #119115 (Update documentation for `--env` compilation flag)
 - #119155 (coverage: Check for `async fn` explicitly, without needing a heuristic)
 - #119159 (Update LLVM submodule)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-20 16:01:46 +00:00
Guillaume Gomez
5906d8f0cf
Rollup merge of #119155 - Zalathar:async-fn, r=compiler-errors
coverage: Check for `async fn` explicitly, without needing a heuristic

The old code used a heuristic to detect async functions and adjust their coverage spans to produce better output. But there's no need to resort to a heuristic when we can just look back at the original definition and check whether the current function is actually an `async fn`.

In addition to being generally nicer, this also gets rid of the one piece of code that specifically cares about `CoverageSpan::is_closure` representing an actual closure. All remaining code that inspects that field just uses it as an indication that the span is a hole that should be carved out of other spans, and then discarded.

That opens up the possibility of introducing other kinds of “hole” spans, e.g. for nested functions/types/macros, and having them all behave uniformly.

---

`@rustbot` label +A-code-coverage
2023-12-20 16:29:55 +01:00
bors
8fca8295cb Auto merge of #119136 - petrochenkov:feedvis3, r=WaffleLapkin
resolve: Eagerly feed closure visibilities

Also factor out all tcx-dependent operations performed for every created definition into `TyCtxt::create_def`.

Addresses https://github.com/rust-lang/rust/pull/118657#discussion_r1421424277
2023-12-20 14:03:00 +00:00
bors
f9d52dc594 Auto merge of #119134 - petrochenkov:feedvis2, r=compiler-errors
resolve: Feed visibilities for unresolved trait impl items

Fixes https://github.com/rust-lang/rust/issues/119073
2023-12-20 11:13:22 +00:00
Vadim Petrochenkov
5e5d82e803 resolve: Eagerly feed closure visibilities
Also factor out all tcx-dependent operations performed for every created definition into `TyCtxt::create_def`
2023-12-20 13:42:58 +03:00
bors
3e4a15ea06 Auto merge of #119156 - matthiaskrgr:rollup-482ow65, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #118691 (Add check for possible CStr literals in pre-2021)
 - #118973 (rustc_codegen_ssa: Don't drop `IncorrectCguReuseType` , make `rustc_expected_cgu_reuse` attr work)
 - #119071 (-Znext-solver: adapt overflow rules to avoid breakage)
 - #119089 (effects: fix a comment)
 - #119094 (Add function ABI and type layout to StableMIR)
 - #119102 (Add arm-none-eabi and armv7r-none-eabi platform-support documentation.)
 - #119107 (subtype_predicate: remove unnecessary probe)

Failed merges:

 - #119135 (Fix crash due to `CrateItem::kind()` not handling constructors)
 - #119141 (Add method to get instance instantiation arguments)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-20 09:14:25 +00:00
Matthias Krüger
d6656af16a
Rollup merge of #119107 - lcnr:uwuwu, r=compiler-errors
subtype_predicate: remove unnecessary probe

There is no reason to probe here. The failure either results in an actual type error, in which cases the probe is useless, or it is used inside of evaluate, in which case we're already inside of the `fn evaluation_probe`, so it is also not necessary.
2023-12-20 09:46:13 +01:00
Matthias Krüger
8b3914ce48
Rollup merge of #119094 - celinval:smir-layout, r=compiler-errors
Add function ABI and type layout to StableMIR

This change introduces a new module to StableMIR named `abi` with information from `rustc_target::abi` and `rustc_abi`, that allow users to retrieve more low level information required to perform bit-precise analysis.

The layout of a type can be retrieved via `Ty::layout`, and the instance ABI can be retrieved via `Instance::fn_abi()`.

To properly handle errors while retrieve layout information, we had to implement a few layout related traits.

r? ```@compiler-errors```
2023-12-20 09:46:12 +01:00
Matthias Krüger
f9c752d931
Rollup merge of #119089 - fmease:dont-ice-on-tilde-const-non-const-trait, r=fee1-dead
effects: fix a comment

r? fee1-dead or compiler
2023-12-20 09:46:12 +01:00
Matthias Krüger
16a231d8eb
Rollup merge of #119071 - lcnr:overflowo, r=compiler-errors
-Znext-solver: adapt overflow rules to avoid breakage

Do not erase overflow constraints if they are from equating the impl header when normalizing[^1].

This should be the minimal change to not break crates depending on the old project behavior of "apply impl constraints while only lazily evaluating any nested goals".

Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/70, see https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg for the reasoning behind this.

Only keeping constraints on overflow for `normalize-to` goals as that's the only thing needed for backcompat. It also allows us to not track the origin of root obligations. The issue with root goals would be something like the following:

```rust
trait Foo {}
trait Bar {}

trait FooBar {}
impl<T: Foo + Bar> FooBar for T {}

// These two should behave the same, rn we can drop constraints for both,
// but if we don't drop `Misc` goals we would only drop the constraints for
// `FooBar` unless we track origins of root obligations.
fn func1<T: Foo + Bar>() {}
fn func2<T: FooBaz>() {}
```

[^1]: mostly, the actual rules are slightly different

r? ``@compiler-errors``
2023-12-20 09:46:11 +01:00
Matthias Krüger
df4d56307b
Rollup merge of #118973 - Enselic:fix-IncorrectCguReuseType, r=michaelwoerister
rustc_codegen_ssa: Don't drop `IncorrectCguReuseType` , make `rustc_expected_cgu_reuse` attr work

In [100753], `IncorrectCguReuseType` accidentally stopped being emitted by removing `diag.span_err(...)`. Begin emitting it again rather than just blindly dropping it, and adjust tests accordingly.

We assume that there are no bugs and that the currently actual CGU reuse is correct. If there are bugs, they will be discovered and fixed eventually, and the tests will then be updated.

[100753]: 706452eba7 (diff-048389738ddcbe0f9765291a29db1fed9a5f03693d4781cfb5aaa97ffb3c7f84)

Closes #118972
2023-12-20 09:46:11 +01:00
Matthias Krüger
f3f9b3043e
Rollup merge of #118691 - chfogelman:improve-cstr-error, r=fmease
Add check for possible CStr literals in pre-2021

Fixes [#118654](https://github.com/rust-lang/rust/issues/118654)

Adds information to errors caused by possible CStr literals in pre-2021.

The lexer separates `c"str"` into two tokens if the edition is less than 2021, which later causes an error when parsing. This error now has a more helpful message that directs them to information about editions. However, the user might also have written `c "str"` in a later edition, so to not confuse people who _are_ using a recent edition, I also added a note about whitespace.

We could probably figure out exactly which scenario has been encountered by examining spans and editions, but I figured it would be better not to overcomplicate the creation of the error too much.

This is my first code PR and I tried to follow existing conventions as much as possible, but I probably missed something, so let me know!
2023-12-20 09:46:10 +01:00
Zalathar
cf6dc7adb3 coverage: Check for async fn explicitly, without needing a heuristic
The old code used a heuristic to detect async functions and adjust their
coverage spans to produce better output. But there's no need to resort to a
heuristic when we can just check whether the current function is actually an
`async fn`.
2023-12-20 18:48:04 +11:00
Zalathar
2a0290a802 coverage: Pass around &ExtractedHirInfo instead of individual fields
This reduces the risk of mixing up `fn_source_span` and `body_span`, and makes
it easier to pass along additional fields as needed.
2023-12-20 18:48:04 +11:00
bors
3095d31a75 Auto merge of #119118 - arttet:feature/fix-arm64e-targets, r=petrochenkov
Fix arm64e-apple-ios target

- [x] [Remove legacy `bitcode` defaults](https://github.com/rust-lang/rust/pull/117364)
- [x] Use LLVM features

Now we have warnings such as

```
'+paca' is not a recognized feature for this target (ignoring feature)
'+pacg' is not a recognized feature for this target (ignoring feature)
```

Because we should use LLVM features.
2023-12-20 07:13:53 +00:00
bors
5810deef69 Auto merge of #119096 - compiler-errors:yeet-unnecessary-param-envs, r=lcnr
Yeet unnecessary param envs

We don't need to pass in param-envs around in the lexical region resolution code (or in `MatchAgainstFreshVars` in the solver), since it is only used to eval some consts in `structurally_relate_tys` which I removed.

This is in preparation for normalizing the outlives clauses in `ParamEnv` for the new trait solver.

r? lcnr
2023-12-20 05:15:44 +00:00
Carter Hunt Fogelman
2c96025874 Improve compiler error for c-strings in pre-2021 2023-12-19 13:28:48 -08:00
bors
f704f3b93b Auto merge of #119112 - Nadrieril:remove-target_blocks-hack, r=matthewjasper
match lowering: Remove the `make_target_blocks` hack

This hack was introduced 4 years ago in [`a1d0266` (#60730)](a1d0266878) to improve LLVM optimization time, specifically noticed in the `encoding` benchmark. Measurements today indicate it is no longer needed.

r? `@matthewjasper`
2023-12-19 21:15:31 +00:00
Vadim Petrochenkov
7571f6f685 resolve: Feed visibilities for unresolved trait impl items 2023-12-19 22:33:26 +03:00
Martin Nordholts
d46df80c73 rustc_codegen_ssa: Don't let IncorrectCguReuseType errors get lost
In [100753], `IncorrectCguReuseType` accidentally stopped being emitted.
Begin emitting it again rather than just blindly dropping it, and adjust
tests accordingly.

[100753]: 706452eba7 (diff-048389738ddcbe0f9765291a29db1fed9a5f03693d4781cfb5aaa97ffb3c7f84)
2023-12-19 20:20:40 +01:00
bors
57ad5058d6 Auto merge of #119084 - aliemjay:perf-env-bounds, r=compiler-errors
fast path for declared_generic_bounds_from_env

~2% perf gain for diesel
2023-12-19 19:17:25 +00:00
Celina G. Val
76b3e6de55 Fix c_variadic flag and add opaque info to PassMode
We should expand the information in PassMode later.
2023-12-19 11:04:34 -08:00
bors
3a539c0889 Auto merge of #118842 - Nadrieril:librarify-further, r=compiler-errors
Make exhaustiveness usable outside of rustc

With this PR, `rustc_pattern_analysis` compiles on stable (with the `stable` feature)! `rust-analyzer` will be able to use it to provide match-related diagnostics and refactors.

Two questions:
- Should I name the feature `nightly` instead of `rustc` for consistency with other crates? `rustc` makes more sense imo.
- `typed-arena` is an optional dependency but tidy made me add it to the allow-list anyway. Can I avoid that somehow?

r? `@compiler-errors`
2023-12-19 17:15:04 +00:00
Michael Goulet
a75d0021ed Remove param env from relation altogether 2023-12-19 17:13:10 +00:00
lcnr
17705ea0a8 add comment 2023-12-19 17:39:48 +01:00
Ali MJ Al-Nasrawy
27e964dbfb fast path for declared_generic_bounds_from_env 2023-12-19 16:07:01 +00:00
Michael Goulet
009cd9c815 Remove unnecessary param-env from lexical region resolution and fully structural relations 2023-12-19 15:10:26 +00:00
Michael Goulet
e6d6b1d92c Do not evaluate in structurally_relate_tys 2023-12-19 15:10:26 +00:00
León Orell Valerian Liehr
ffdc6c7b65
effects: fix comment 2023-12-19 14:25:24 +01:00
bjorn3
d5c38ded26 Merge commit '3a9bf729322fb5035518f99b9d76a742bf7c124e' into sync_cg_clif-2023-12-19 2023-12-19 12:46:39 +00:00
Artyom Tetyukhin
fd0033c777
Use LLVM features for arm64e_apple_ios target
We need to use LLVM features here. Otherwise we get warnings such as
'+paca' is not a recognized feature for this target (ignoring feature)
2023-12-19 16:46:30 +04:00
Artyom Tetyukhin
3f8704355b
Remove legacy bitcode defaults 2023-12-19 16:40:33 +04:00
bors
69e4545a8d Auto merge of #119110 - matthiaskrgr:rollup-vr6ha8x, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #119087 (Update books)
 - #119091 (Use alias-eq in structural normalization)
 - #119098 (Adjust the ignore-compare-mode-next-solver for hangs)
 - #119100 (Add the function body span to StableMIR)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-12-19 10:45:09 +00:00
Nadrieril
31bad13f82 Remove the make_target_blocks hack
It was introduced 4 years ago in a1d0266878 to improve LLVM
optimization time. Measurements today indicate it is no longer needed.
2023-12-19 11:37:39 +01:00
Matthias Krüger
739364b77c
Rollup merge of #119100 - celinval:smir-body-span, r=compiler-errors
Add the function body span to StableMIR

We were missing the body span, which differs from the function definition span, since it covers the entire function body.

r? `@ouz-a`
2023-12-19 10:50:09 +01:00
Matthias Krüger
9a72b7d04f
Rollup merge of #119091 - compiler-errors:alias-eq-in-structural-normalize, r=lcnr
Use alias-eq in structural normalization

We don't need to register repeated normalizes-to goals in a loop in structural normalize, but instead we can piggyback on the fact that alias-eq will already normalize aliases until they are rigid.

This fixes rust-lang/trait-system-refactor-initiative#78.

r? lcnr
2023-12-19 10:50:08 +01:00
bors
32f5db9890 Auto merge of #119093 - michaelwoerister:mcp533-18, r=petrochenkov
Replace some instances of FxHashMap/FxHashSet with stable alternatives (mostly in rustc_hir and rustc_ast_lowering)

Part of https://github.com/rust-lang/compiler-team/issues/533. We should be getting close to being able to remove the HashStable impl of HashMap.
2023-12-19 08:46:02 +00:00
bors
be69926a73 Auto merge of #119074 - leohowell:new-aarch64-apple-watchos-target, r=wesleywiser
Add new tier 3 aarch64-apple-watchos target

Apple Xcode 14/15 releases add a new apple watchos target architecture arm64 out of arm64_32 and armv7k, now add a new tier 3 target support for this target.

### Tier 3 Target Requirements
Adds support for Apple WatchOS aarch64-apple-watchos target.

Below are details on how this target meets the requirements for tier 3:

> tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

`@leohowell`  has volunteered to be the target maintainer. I am also happy to help if a second maintainer is required.

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

Uses the same naming as the LLVM target, and the same convention as other Apple targets.

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

I don't believe there is any ambiguity here.

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

I don't see any legal issues here.

> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
> If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

I see no issues with any of the above.

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Only relevant to those making approval decisions.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

core and alloc can be used. std support will be added in a subsequent PR.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Use --target= option to cross compile, just like any target. Tests can be run using the WatchOS simulator (see https://developer.apple.com/documentation/xcode/running-your-app-in-the-simulator-or-on-a-device).

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I don't foresee this being a problem.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

No other targets should be affected by the pull request.

r? compiler-team
2023-12-19 06:47:58 +00:00
lcnr
df5b604945 subtype_predicate: remove unnecessary probe 2023-12-19 07:40:06 +01:00
bors
e999d8b6e1 Auto merge of #119047 - mu001999:fix/118772, r=wesleywiser
Check generic params after sigature for main-fn-ty

Fixes #118772
2023-12-19 02:41:58 +00:00
Celina G. Val
36bb79fc5e Add the function body span to StableMIR 2023-12-18 17:13:49 -08:00
bors
59096cdad0 Auto merge of #119061 - compiler-errors:async-gen-abi, r=wesleywiser
Desugar `yield` in `async gen` correctly, ensure `gen` always returns unit

1. Ensure `async gen` blocks desugar `yield $expr` to `task_context = yield async_gen_ready($expr)`. Previously we were not assigning the `task_context` correctly, meaning that `yield` expressions in async generators returned type `ResumeTy` instead of `()`, and that we were not storing the `task_context`  (which is probably unsound if we were reading the old task-context which has an invalidated borrow or something...)
2. Ensure that all `(async?) gen` blocks and `(async?) gen` fns return unit. Previously we were only checking this for `gen fn`, meaning that `gen {}` and `async gen {}` and `async gen fn` were allowed to return values that weren't unit. This is why #119058 was an ICE rather than an E0308.

Fixes #119058.
2023-12-19 00:42:50 +00:00
bors
3f28fe1334 Auto merge of #119023 - compiler-errors:fn-trait-constness, r=fee1-dead
Check `FnPtr`/`FnDef` built-in fn traits correctly with effects

1. Teach the (old) trait solver how to handle the constness for built-in impls of the `Fn*` family of traits. This unfortunately doesn't support const closures just yet.
2. Fix the `const_eval_select`. It turns out that the `where` clause bounds on `const_eval_select` force the effect parameter for both fndefs to be `true` -- with effects, we will leave off any explicit where clauses and register these obligations manually.

I can elaborate on (2.) if you think it needs a better explanation!

r? fee1-dead
2023-12-18 20:44:09 +00:00
Michael Goulet
faea6ad579 Check const_eval_select intrinsic correctly 2023-12-18 20:28:06 +00:00
Michael Goulet
69f360d00c Check FnPtr/FnDef built-in fn traits correctly with effects 2023-12-18 20:28:06 +00:00
Michael Woerister
115885ba7e Replace some instances of FxHashMap/FxHashSet with stable alternatives (mostly in rustc_hir and rustc_ast_lowering)
Part of https://github.com/rust-lang/compiler-team/issues/533
2023-12-18 21:03:32 +01:00