28071 Commits

Author SHA1 Message Date
bors
5f6ee65f59 Auto merge of - chenyukang:yukang-fix-diag-generic-parameters, r=cjgillot
Cleanup unused labels in messages.ftl

These labels were not used, maybe because we removed the diagnostics but forgot them.
2023-09-12 11:29:22 +00:00
bors
cc7a9d6972 Auto merge of - cjgillot:const-prop-aggregate, r=oli-obk
Read from non-scalar constants and statics in dataflow const-prop

DataflowConstProp is designed to handle scalar values. When MIR features an assignment from a non-scalar constant, we need to manually decompose it into the custom state space.

This PR tweaks interpreter callbacks to allow reusing `eval_mir_constant` without having a stack frame to get a span from.

r? `@oli-obk`
cc `@jachris`
2023-09-12 09:02:27 +00:00
John Kåre Alsaker
f8ad88be81 Use UnhashMap for the index 2023-09-12 08:59:37 +02:00
John Kåre Alsaker
734e5a1fbd Encode the number of dep kinds encountered in the dep graph 2023-09-12 08:51:39 +02:00
John Kåre Alsaker
8c5bc990cc Store a index per dep node kind 2023-09-12 08:46:17 +02:00
bors
6c03617142 Auto merge of - matthiaskrgr:rollup-bo82nn9, r=matthiaskrgr
Rollup of 3 pull requests

Successful merges:

 -  (Add `i686-pc-windows-gnullvm` triple)
 -  (Add source type for invalid bool casts)
 -  (Remove spastorino as "on vacation")

r? `@ghost`
`@rustbot` modify labels: rollup
2023-09-12 05:23:16 +00:00
Matthias Krüger
32cf2c4b68
Rollup merge of - asquared31415:cast_diag, r=WaffleLapkin
Add source type for invalid bool casts

Also adds tests for casting various types to `bool` that were otherwise untested.

r? `@WaffleLapkin`
2023-09-12 06:34:46 +02:00
Matthias Krüger
8e157ecd65
Rollup merge of - mati865:i686-pc-windows-gnullvm-triple, r=wesleywiser
Add `i686-pc-windows-gnullvm` triple

With various fixes that are already present in the code, a fully working i686 target can join other targets in `*-windows-gnullvm` family. Again this will be mostly useful for MSYS2 right now but I plan to open MCP for providing at least prebuilt std for `windows-gnullvm` as the next step which will expand usability of these targets.

Tier 3 policy:

> A 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.)

I pledge to do my best maintaining it, MSYS2 is one of interested consumers. Previously added `gnullvm` triples proved there is not much maintenance 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.

This triple name is consistent with other targets and was discussed at [`t-compiler/LLVM+mingw-w64 Windows targets`](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets)

> 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 think the explanation in platform support doc is enough to make this aspect clear.

> 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.

It's using open source tools only.

> The target must not introduce license incompatibilities.

It's even more liberal than already existing `*-pc-windows-gnu`.

> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).

Understood.

> 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.

There are no new dependencies/features required.

> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. 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.

As previously said it's using open source tools only.

> "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.

There are no such terms present.

> 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.

I'm not the reviewer here.

> 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.

Again I'm not the reviewer here.

> 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.

It seems to work, at least for cross compilation.

> 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 binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.

Building is described in platform support doc, running tests doesn't work right now (without hacks) because Rust's build system doesn't seem to support testing targets built from `.json`.
Docs will be updated once this lands in beta allowing master branch to build and run tests without `.json` files.

> 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.

Understood.

> 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.

Understood.

 > 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.

I believe I didn't break any other 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.

I think there are no such problems in this PR.
2023-09-12 06:34:45 +02:00
bors
366dab13f7 Auto merge of - RalfJung:interpret-abi-compat, r=oli-obk
interpret: change ABI-compat test to be type-based

This makes the test consistent across targets. Otherwise the chances are very high that ABI mismatches get accepted on x86_64 but still fail on many other targets with more complicated ABIs.

This implements (most of) the rules described in https://github.com/rust-lang/rust/pull/115476.
2023-09-12 03:34:55 +00:00
bors
36b8e4aa75 Auto merge of - Alexendoo:clippy-doc-comments, r=notriddle,Manishearth,flip1995
Reuse rustdoc's doc comment handling in Clippy

Moves `source_span_for_markdown_range` and `span_of_attrs` (renamed to `span_of_fragments`) to `rustc_resolve::rustdoc` so it can be used in Clippy

Fixes https://github.com/rust-lang/rust-clippy/issues/10277
Fixes https://github.com/rust-lang/rust-clippy/issues/5593
Fixes https://github.com/rust-lang/rust-clippy/issues/10263
Fixes https://github.com/rust-lang/rust-clippy/issues/2581
2023-09-12 01:45:24 +00:00
bors
725afd287a Auto merge of - Zalathar:mapgen, r=wesleywiser
coverage: Clean up encoding of per-function coverage mapping payloads

This PR contains several small improvements to the code in `rustc_codegen_llvm::coverageinfo::mapgen` that prepares a function's coverage mappings for FFI, and passes them over to LLVM to be encoded into a vector of bytes.

These changes are in preparation for some future changes to the coverage implementation, but they should all stand on their own as worthwhile.

There shouldn't be any changes to the resulting coverage mappings, as verified by the existing `tests/coverage-map` and `tests/run-coverage` suites.

The changes are mostly independent of each other, though they are indirectly affected by the indentation changes made when introducing `GlobalFileTable`.
2023-09-12 00:03:09 +00:00
yukang
f9a9ff20a2 cleanup on messages 2023-09-12 07:27:17 +08:00
bors
b4e54c6e39 Auto merge of - matthiaskrgr:rollup-byf3lvq, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 -  (Extract parallel operations in `rustc_data_structures::sync` into a new `parallel` submodule)
 -  (Add regression test for LLVM 17-rc3 miscompile)
 -  (Don't ICE when computing ctype's `repr_nullable_ptr` for possibly-unsized ty)
 -  (fix homogeneous_aggregate not ignoring some ZST)
 -  (Some more small driver refactors)
 -  (Allow loading the SMIR for constants and statics)
 -  (Add a test for )
 -  (Update books)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-09-11 20:53:42 +00:00
ouz-a
3ec0165f5f Remove assert that checks type equality 2023-09-11 23:08:40 +03:00
Matthias Krüger
2a087be735
Rollup merge of - oli-obk:smir_consts, r=compiler-errors
Allow loading the SMIR for constants and statics

cc https://github.com/rust-lang/project-stable-mir/issues/34

before this PR we were ICEing when trying to access the SMIR of anything other than functions
2023-09-11 21:16:23 +02:00
Matthias Krüger
c943ec2fba
Rollup merge of - bjorn3:some_driver_refactors, r=compiler-errors
Some more small driver refactors

To improve clarity and simplify some code.
2023-09-11 21:16:22 +02:00
Matthias Krüger
279e2576a0
Rollup merge of - RalfJung:homogeneous, r=davidtwco
fix homogeneous_aggregate not ignoring some ZST

This is an ABI-breaking change, because it fixes bugs in our ABI code. I'm not sure what that means for this PR, we don't really have a process for such changes, do we? I can only hope nobody relied on the old buggy behavior.

Fixes https://github.com/rust-lang/rust/issues/115664
2023-09-11 21:16:22 +02:00
Matthias Krüger
5a2b589ac7
Rollup merge of - compiler-errors:ctypes-unsized, r=davidtwco
Don't ICE when computing ctype's `repr_nullable_ptr` for possibly-unsized ty

We may not always be able to compute the layout of a type like `&T` when `T: ?Sized`, even if we're able to estimate its size skeleton.

r? davidtwco

Fixes 
2023-09-11 21:16:21 +02:00
Matthias Krüger
f3cc59b741
Rollup merge of - Zoxc:parallel-extract, r=wesleywiser
Extract parallel operations in `rustc_data_structures::sync` into a new `parallel` submodule

This extracts parallel operations in `rustc_data_structures::sync` into a new `parallel` submodule. This cuts down on the size of the large `cfg_if!` in `sync` and makes it easier to compare between serial and parallel variants.
2023-09-11 21:16:20 +02:00
bors
e2b3676733 Auto merge of - oli-obk:patch_tait_rpit_order_check, r=lcnr,compiler-errors
Bubble up opaque <eq> opaque operations instead of picking an order

In case we are in `Bubble` mode (meaning every opaque type that is defined in the current crate is treated as if it were in its defining scope), we don't try to register an opaque type as the hidden type of another opaque type, but instead bubble up an obligation to equate them at the query caller site. Usually that means we have a `DefiningAnchor::Bind` and thus can reliably figure out whether an opaque type is in its defining scope. Where we can't, we'll error out, so the default is sound.

With this change we start using `AliasTyEq` predicates in the old solver, too.

fixes https://github.com/rust-lang/rust/issues/108498

But also regresses `tests/ui/impl-trait/anon_scope_creep.rs`. Our use of `Bubble` for `check_opaque_type_well_formed` is going to keep biting us.

r? `@lcnr` `@compiler-errors`
2023-09-11 19:01:38 +00:00
asquared31415
e36adff4c2 add source type for invalid bool casts 2023-09-11 18:10:07 +00:00
Oli Scherer
930affa39d Bubble up opaque <eq> opaque operations instead of picking an order 2023-09-11 16:53:39 +00:00
bors
0a199e4e93 Auto merge of - matthiaskrgr:rollup-khwbjj7, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 -  (fix overflow in array length computation)
 -  (bootstrap/format: remove unnecessary paths.push)
 -  (Update mailmap)
 -  (Implement fallback for effect param)
 -  (Call `LateLintPass::check_attribute` from `with_lint_attrs`)
 -  (Point out if a local trait has no implementations)
 -  (Improve diagnostic for generic params from outer items (E0401))
 -  (rustdoc: Add missing "Aliased type" title in the sidebar)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-09-11 16:50:22 +00:00
Camille GILLOT
6984030f80 Use write_immediate. 2023-09-11 16:29:42 +00:00
Camille GILLOT
bcfe1a4bf2 Remove cur_span hook. 2023-09-11 16:29:42 +00:00
Camille GILLOT
24adf07e5f Reuse throw_machine_stop_str! macro. 2023-09-11 16:29:41 +00:00
Camille GILLOT
4901893721 Inline callback. 2023-09-11 16:29:41 +00:00
Camille GILLOT
d278ce126c Return ImmTy in discriminant_for_variant. 2023-09-11 16:29:41 +00:00
Camille GILLOT
1d6a32c920 Interpret Immediate::Uninit as Bottom. 2023-09-11 16:29:41 +00:00
Camille GILLOT
b851e554dd Support CopyForDeref. 2023-09-11 16:29:41 +00:00
Camille GILLOT
82f0468009 Handle reading statics. 2023-09-11 16:29:41 +00:00
Camille GILLOT
6ad6b4381c Support non-scalar constants. 2023-09-11 16:29:41 +00:00
Matthew Jasper
b011a0a13b Reduce double errors for invalid let expressions
Previously some invalid let expressions would result in both a feature
error and a parsing error. Avoid this and ensure that we only emit the
parsing error when this happens.
2023-09-11 16:17:06 +00:00
Matthew Jasper
333388fd3c Move let expression checking to parsing
There was an incomplete version of the check in parsing and a second
version in AST validation. This meant that some, but not all, invalid
uses were allowed inside macros/disabled cfgs. It also means that later
passes have a hard time knowing when the let expression is in a valid
location, sometimes causing ICEs.

- Add a field to ExprKind::Let in AST/HIR to mark whether it's in a
  valid location.
- Suppress later errors and MIR construction for invalid let
  expressions.
2023-09-11 15:51:18 +00:00
Matthew Jasper
7b61f7f002 Don't create drop scopes after item statements
These scopes would not exist in MIR and can cause ICEs with invalid uses
of let expressions.
2023-09-11 15:51:18 +00:00
Matthias Krüger
8b49731211
Rollup merge of - fmease:fix-e0401, r=compiler-errors
Improve diagnostic for generic params from outer items (E0401)

Generalize the wording of E0401 to talk about *outer items* instead of *outer functions* since the current phrasing is outdated. The outer item can be a function, constant, trait, ADT or impl block (see the new UI test for the more exotic examples).

Further, don't suggest introducing generic parameters to constant items unless the feature `generic_const_items` is enabled.

Lastly, make E0401 translatable while we're at it.

Fixes .
2023-09-11 17:03:32 +02:00
Matthias Krüger
f279afb455
Rollup merge of - compiler-errors:no-impls, r=davidtwco
Point out if a local trait has no implementations

Slightly helps with 
2023-09-11 17:03:32 +02:00
Matthias Krüger
d24f575722
Rollup merge of - Alexendoo:lint-pass-check-attribute, r=oli-obk
Call `LateLintPass::check_attribute` from `with_lint_attrs`

Fixes 

For regular `register_late_pass` lints also means that `last_node_with_lint_attrs` is correct when in `check_attribute`, I've added a test that previously failed for `clippy::allow_attributes`

As far as I can see the only late lint in rustc that uses `check_attribute` is `unstable_features` which is allow by default and deprecated so this is mostly for clippy (or future rustc lints)
2023-09-11 17:03:32 +02:00
Matthias Krüger
e7a347baf8
Rollup merge of - fee1-dead-contrib:effect-fallback, r=oli-obk
Implement fallback for effect param

r? `@oli-obk` or `@lcnr`

tracking issue for this ongoing work: https://github.com/rust-lang/rust/issues/110395
2023-09-11 17:03:31 +02:00
Matthias Krüger
b99af95713
Rollup merge of - reez12g:issue-114912, r=davidtwco
fix overflow in array length computation

addressing https://github.com/rust-lang/rust/issues/114912
2023-09-11 17:03:29 +02:00
bors
3ebb5629d1 Auto merge of - surechen:114896, r=davidtwco
Fix incorrect mutable suggestion information for binding in ref pattern like:  `let &b = a;`

fixes 

I find we have to get pat_span but not local_decl.source_info.span for suggestion. In `let &b = a;`  pat_span is &b. I think check `let &b = a` in hir to make sure it is hir::Node::Local(hir::Local {pat: hir::Pat{kind: hir::PatKind::Ref(.......   can distinguish it from other situation, but I'm not sure.

If my processing method is not accurate, please guide me to modify it, thank you.

r? `@davidtwco`
2023-09-11 15:02:59 +00:00
lcnr
eac55eec9e dedup GoalEvaluationStep and GoalCandidate
also handle 2 panics when dumping proof trees for the whole test suite

- need to actually tell the proof tree builder about overflow
- need to handle a recursion_limit of 0 :<
2023-09-11 15:50:09 +02:00
Deadbeef
9654d5ceaf add is_host_effect to GenericParamDefKind::Const and address review 2023-09-11 13:18:36 +00:00
bors
68c2f5ba0f Auto merge of - chenyukang:yukang-fix-62387-iter-mut, r=davidtwco
suggest iter_mut() where trying to modify elements from .iter()

Fixes https://github.com/rust-lang/rust/issues/115259
Fixes https://github.com/rust-lang/rust/issues/62387
2023-09-11 12:41:30 +00:00
lcnr
8225a2e9ec inspect: strongly typed CandidateKind 2023-09-11 13:11:32 +02:00
bors
55e5c9d705 Auto merge of - cjgillot:default-relative-spans, r=davidtwco
Enable incremental-relative-spans by default.

This was enabled on nightly in https://github.com/rust-lang/rust/pull/84762.

It has been a while, without obvious bugs. It's time to enable it by default for incremental runs.
2023-09-11 10:46:55 +00:00
lcnr
006d599435 revision -> iteration for added_goals_evaluation 2023-09-11 11:51:32 +02:00
lcnr
01f3da6b24 inspect: handle None in nested 2023-09-11 11:51:32 +02:00
lcnr
fc452e2ed3 split GoalEvaluation and CanonicalGoalEvaluation
the unnormalized goal is in the callers inference context, while
anything inside of the `CanonicalGoalEvaluation` is inside of
a new one.
2023-09-11 11:51:32 +02:00
bors
5d62ab8981 Auto merge of - weihanglo:merge-check-and-lint, r=oli-obk
Make unknown/renamed/removed lints passed via command line respect lint levels
2023-09-11 08:56:29 +00:00