Commit Graph

2894 Commits

Author SHA1 Message Date
Yuri Astrakhan
950e3d9989 Cleaner assert_eq! & assert_ne! panic messages
Modify panic message for `assert_eq!`, `assert_ne!`, the currently unstable `assert_matches!`, as well as the corresponding `debug_assert_*` macros.

```rust
assert_eq!(1 + 1, 3);
assert_eq!(1 + 1, 3, "my custom message value={}!", 42);
```

```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion failed: `(left == right)`
  left: `2`,
 right: `3`
```
```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion failed: `(left == right)`
  left: `2`,
 right: `3`: my custom message value=42!
```

```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion `left == right` failed
  left: 2
 right: 3
```

```plain
thread 'main' panicked at $DIR/main.rs:6:5:
assertion `left == right` failed: my custom message value=42!
  left: 2
 right: 3
```

This PR is a simpler subset of the #111030, but it does NOT stringify the original left and right source code assert expressions, thus should be faster to compile.
2023-08-15 16:53:10 -04:00
Guillaume Gomez
31a41310ee
Rollup merge of #114831 - compiler-errors:next-solver-projection-subst-compat, r=lcnr
Check projection args before substitution in new solver

Don't ICE when an impl has the wrong kind of GAT arguments

r? lcnr
2023-08-15 14:29:50 +02:00
Guillaume Gomez
81efd47aa7
Rollup merge of #114830 - compiler-errors:ui-test-annotations, r=petrochenkov
Clean up some bad UI testing annotations

These annotations do nothing 😅
2023-08-15 14:29:50 +02:00
Guillaume Gomez
da4e7bd0cd
Rollup merge of #114829 - compiler-errors:next-solver-only-unsize-to-dyn-once, r=lcnr
Separate `consider_unsize_to_dyn_candidate` from other unsize candidates

Move the unsize candidate assembly *just for* `T -> dyn Trait` out of `assemble_candidates_via_self_ty` so that we only consider it once, instead of for every normalization step of the self ty. This makes sure that we don't assemble several candidates that are equal modulo normalization when we really don't care about normalizing the self type of an `T: Unsize<dyn Trait>` goal anyways.

Fixes rust-lang/trait-system-refactor-initiative#57

r? lcnr
2023-08-15 14:29:49 +02:00
Guillaume Gomez
47bdda2b45
Rollup merge of #114828 - compiler-errors:next-solver-probe-upcasting, r=lcnr
Probe when assembling upcast candidates so they don't step on eachother's toes in new solver

Lack of a probe causes one candidate to disqualify the other due to inference side-effects.

r? lcnr
2023-08-15 14:29:49 +02:00
Guillaume Gomez
e4b9e72e58
Rollup merge of #114827 - compiler-errors:next-solver-dyn-safe-candidates, r=lcnr
Only consider object candidates for object-safe dyn types in new solver

We apparently allow this per RFC2027 💀

r? lcnr
2023-08-15 14:29:48 +02:00
Guillaume Gomez
0e7f9e576f
Rollup merge of #114825 - cuviper:gimli-0.28, r=compiler-errors
Upgrade std to gimli 0.28.0

Gimli 0.28 removed its `From<EndianSlice> for &[u8]` that was the root cause of #113238.

This dependency update mirrors rust-lang/backtrace-rs#557, but since that doesn't require any code changes in `backtrace`, we can also apply that right away for our nested `std/backtrace` feature.
2023-08-15 14:29:48 +02:00
Guillaume Gomez
dd76268ac5
Rollup merge of #114820 - ehuss:unknown-lint-mod-warning, r=compiler-errors
Add test for unknown_lints from another file.

This adds a test for #84936 which was incidentally fixed via #97266. It is a strange issue where `#![allow(unknown_lints)]` at the crate root was not applying to unknown lints that fired in a non-inline-module. I did not dig further into how #97266 fixed it, but I did verify it. I couldn't find any existing tests which did anything similar.

Closes #84936
2023-08-15 14:29:47 +02:00
bors
a32978a5e8 Auto merge of #114023 - compiler-errors:coinductive-cycle-lint, r=lcnr
Warn on inductive cycle in coherence leading to impls being considered not overlapping

This PR implements a `coinductive_overlap_in_coherence` lint (#114040), which warns users against cases where two impls are considered **not** to overlap during coherence due to an inductive cycle disproving one of the predicates after unifying the two impls.

Cases where this lint fires will become an overlap error if we ever move to coinduction, so I'd like to make this a warning to avoid having more crates take advantage of this behavior in the mean time. Also, since the new trait solver treats inductive cycles as ambiguity, not an error, this is a blocker for landing the new trait solver in coherence.
2023-08-15 06:36:05 +00:00
Michael Goulet
0e20155662 more nits 2023-08-15 03:44:21 +00:00
Michael Goulet
d2a14df70e nits
Co-authored-by: lcnr <rust@lcnr.de>
2023-08-15 03:40:19 +00:00
Michael Goulet
56f5704ff8 Implement lint against coinductive impl overlap 2023-08-15 03:40:19 +00:00
Michael Goulet
2ae4bedd85 more span info 2023-08-15 03:40:19 +00:00
bors
d7e751006c Auto merge of #113679 - chenyukang:yukang-fix-lint-113459, r=cjgillot
Match scrutinee need necessary parentheses for structs

Fixes #113459
2023-08-15 03:21:47 +00:00
Michael Goulet
77c6c38add Check projection arguments before substitution 2023-08-15 01:03:33 +00:00
Michael Goulet
dc946649f5 Clean up some bad ui testing annotations 2023-08-15 01:03:09 +00:00
Michael Goulet
7d8563c602 Separate consider_unsize_to_dyn_candidate from other unsize candidates 2023-08-15 01:02:43 +00:00
Michael Goulet
ab126c2a4e Probe when assembling upcast candidates so they don't step on eachother's toes 2023-08-15 01:02:13 +00:00
Michael Goulet
e8ab56fbb4 Only consider object candidates for object-safe dyn types 2023-08-15 01:01:44 +00:00
Josh Stone
677afb4b45 Add a regression test for #113238 2023-08-14 16:57:51 -07:00
bors
180dffba14 Auto merge of #113658 - Dirreke:csky-unknown-linux-gunabiv2, r=bjorn3
add a csky-unknown-linux-gnuabiv2 target

This is the rustc side changes to support csky based Linux target(`csky-unknown-linux-gnuabiv2`).

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.

> 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 `csky`  section is the arch name and the `unknown-linux` section is the same as other linux target, and `gnuabiv2` is from the  cross-compile toolchain of  `gcc`

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

No new license

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

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 supports for std

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

I have added the documentation, and I think it's clear.

> 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-08-14 21:53:27 +00:00
Matthias Krüger
378c2fd644
Rollup merge of #114752 - RickleAndMortimer:issue-113788-fix, r=compiler-errors
fixed *const [type error] does not implement the Copy trait

Removes "error: arguments for inline assembly must be copyable" when moving an unknown type

Fixes: #113788
2023-08-14 21:57:51 +02:00
Eric Huss
9dda6b5d35 Add test for unknown_lints from another file. 2023-08-14 12:05:53 -07:00
nxya
cac7c127a2 fixed *const [type error] does not implement the Copy trait 2023-08-14 14:07:46 -04:00
dirreke
e676afbafe fix the error check 2023-08-15 00:57:18 +08:00
bors
475be26d99 Auto merge of #114781 - fee1-dead-contrib:param-impl-source, r=davidtwco
Remove constness from `ImplSource::Param`
2023-08-14 15:24:41 +00:00
Dirreke
9e5fb333f7 add features-gate for csky target feature 2023-08-14 23:02:36 +08:00
Dirreke
8c51e28bd5 add rustc_codegen_ssa support for csky and correct some code 2023-08-14 23:02:36 +08:00
lcnr
95fddbc501 check for non-defining uses of RPIT 2023-08-14 15:25:20 +02:00
yukang
c44b35e1c3 match scrutinee need necessary parentheses for structs 2023-08-14 18:05:13 +08:00
Deadbeef
f441fa08da Remove constness from ImplSource::Param 2023-08-14 02:17:30 +00:00
bors
3071e0aef6 Auto merge of #114787 - compiler-errors:issue-114783, r=jackh726
Select obligations before processing wf obligation in `compare_method_predicate_entailment`

We need to select obligations before processing the WF obligation for the `IMPLIED_BOUNDS_ENTAILMENT` lint, since it skips over type variables.

Fixes #114783

r? `@jackh726`
2023-08-14 00:33:17 +00:00
bors
e81522aa0e Auto merge of #114742 - compiler-errors:opaques-are-not-injective, r=aliemjay
TAITs do not constrain generic params

Fixes #108425

Not sure if I should rework those two failing tests. I guess `tests/ui/type-alias-impl-trait/coherence.rs` could just have the type parameter removed from it? IDK what `tests/ui/type-alias-impl-trait/coherence_generalization.rs` is even testing, though.

r? `@aliemjay`
cc `@lcnr` `@oli-obk` (when he's back from 🌴)
2023-08-13 22:47:14 +00:00
Michael Goulet
b6b5a65ae6 Select obligations before processing wf obligation in compare_method_predicate_entailment 2023-08-13 22:22:15 +00:00
bors
2b26bf5894 Auto merge of #114758 - fmease:fix-nice-re-err-ice-gci, r=cjgillot
Don't crash when reporting nice region errors for generic const items

Fixes #114714.
2023-08-13 14:30:49 +00:00
bors
570601f0aa Auto merge of #114757 - Urgau:transmute-with-invalid_reference_casting, r=est31
Also consider `mem::transmute` with the `invalid_reference_casting` lint

This PR extend the `invalid_reference_casting` lint with regard to the `std::mem::transmute` function.

```
error: casting `&T` to `&mut T` is undefined behavior, even if the reference is unused, consider instead using an `UnsafeCell`
  --> $DIR/reference_casting.rs:27:16
   |
LL |     let _num = &mut *std::mem::transmute::<_, *mut i32>(&num);
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

*I encourage anyone reviewing this PR to do so [without whitespaces](https://github.blog/2011-10-21-github-secrets/#whitespace).*
2023-08-13 12:46:00 +00:00
bors
7455aa5395 Auto merge of #114457 - lcnr:trait_ref_is_knowable-normalize, r=compiler-errors
normalize in `trait_ref_is_knowable` in new solver

fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/51

Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further

I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.

r? `@compiler-errors`
2023-08-13 05:18:27 +00:00
lcnr
9eeaf1fd13 normalize in trait_ref_is_knowable in new solver 2023-08-12 20:37:53 +02:00
bors
cbb48a5e93 Auto merge of #114756 - matthiaskrgr:rollup-4m7l4p6, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #94455 (Partially stabilize `int_roundings`)
 - #114132 (Better Debug for Vars and VarsOs)
 - #114584 (E0277 nolonger points at phantom `.await`)
 - #114667 (Record binder for bare trait object in LifetimeCollectVisitor)
 - #114692 (downgrade `internal_features` to warn)
 - #114703 (Cover ParamConst in smir)
 - #114734 (Mark oli as "on vacation")

r? `@ghost`
`@rustbot` modify labels: rollup
2023-08-12 17:51:16 +00:00
Michael Goulet
5c95e7743b Fix tests
Co-authored-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com>
2023-08-12 17:18:46 +00:00
Michael Goulet
d0c826cfc2 Opaques do not constrain generic params 2023-08-12 17:14:13 +00:00
bors
1e836d12d3 Auto merge of #114710 - Urgau:fix-expect-dead_code-114557, r=cjgillot
Respect `#[expect]` the same way `#[allow]` is with the `dead_code` lint

This PR makes the `#[expect]` attribute being respected in the same way the `#[allow]` attribute is with the `dead_code` lint.

The fix is much more involved than I would have liked (and it's not because I didn't tried!), because the implementation took advantage of the fact that firing a lint in a allow context is a nop (for the user, as the lint is suppressed) to not fire-it at all.

And will it's fine for `#[allow]`, it definitively isn't for `#[expect]`, as the presence and absence of the lint is significant. So a big part of the PR is just adding the context information of whenever an item is on the worklist because of an `[allow]`/`#[expect]` or not.

Fixes https://github.com/rust-lang/rust/issues/114557
2023-08-12 15:14:42 +00:00
León Orell Valerian Liehr
1a18158891
Don't crash when reporting nice region errors for generic const items 2023-08-12 15:34:28 +02:00
Urgau
b517dd5bc9 Also consider transmute with the invalid_reference_casting lint 2023-08-12 13:05:44 +02:00
Matthias Krüger
a12c329b35
Rollup merge of #114667 - compiler-errors:issue-114664, r=davidtwco
Record binder for bare trait object in LifetimeCollectVisitor

The `LifetimeCollectVisitor` had a bug where it was not recording the binder of bate trait objects. This was uncovered in #114487, when I changed opaque type lowering to ICE if it encountered a captured fresh lifetime with no def-id to map back to: https://github.com/rust-lang/rust/pull/114487/files#diff-ad0c15bbde97a607d4758ec7eaf88248be5d6b8ae084dfc84127f81e3f7a9bb4R1585

Fixes #114664
2023-08-12 12:06:36 +02:00
Matthias Krüger
83756d97a8
Rollup merge of #114584 - darklyspaced:master, r=cjgillot
E0277 nolonger points at phantom `.await`

fixes #113203
2023-08-12 12:06:35 +02:00
Jack Huey
3028dc4ef7 Only check outlives goals on impl compared to trait 2023-08-11 21:09:17 -04:00
bors
4d7a80d486 Auto merge of #114672 - lenawanel:master, r=compiler-errors
make `typeid::typeid_itanium_cxx_abi::transform_ty` evaluate length in array types

the ICE in https://github.com/rust-lang/rust/issues/114275 was caused by `transform_ty`
in compiler/rustc_symbol_mangling/src/typeid/typeid_itanium_cxx_abi.rs encountering an unevaluated const, while expecting it to already be evaluated.
2023-08-11 09:30:41 +00:00
bors
a07bc13e14 Auto merge of #114718 - compiler-errors:rollup-1am5rpn, r=compiler-errors
Rollup of 7 pull requests

Successful merges:

 - #114599 (Add impl trait declarations to SMIR)
 - #114622 (rustc: Move `crate_types` and `stable_crate_id` from `Session` to `GlobalCtxt`)
 - #114662 (Unlock trailing where-clauses for lazy type aliases)
 - #114693 (Remove myself from the review rotation)
 - #114694 (make the provisional cache slightly less broken)
 - #114705 (Add spastorino to mailmap)
 - #114712 (Fix a couple of bad comments)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-08-11 04:17:57 +00:00
Michael Goulet
a04dfc32e6
Rollup merge of #114694 - lcnr:provisional-cache, r=compiler-errors
make the provisional cache slightly less broken

It is still broken for the following cycles:
```mermaid
graph LR
   R["R: coinductive"] --> A["A: inductive"]
   R --> B["B: coinductive"]
   A --> B
   B --> R
```
the `R -> A -> B -> R` cycle should be considered to not hold, as it is mixed, but because we first put `B` into the cache from the `R -> B -> R` cycle which is coinductive, it does hold.

This issue will also affect our new coinduction approach. Longterm cycles are coinductive as long as one step goes through an impl where-clause, see f4fc5bae36/crates/formality-prove/src/prove/prove_wc.rs (L51-L62). Here we would first have a fully inductive cycle `R -> B -> R` which is then entered by a cycle with a coinductive step `R -> A -coinductive-> B -> R`.

I don't know how to soundly implement a provisional cache for goals not on the stack without tracking all cycles the goal was involved in and whether they were inductive or not. We could then only use goals from the cache if the *inductivity?* of every cycle remained the same. This is a mess to implement. I therefore want to rip out the provisional cache entirely, but will wait with this until I talked about it with `@nikomatsakis.`

r? `@compiler-errors`
2023-08-10 21:17:09 -07:00