Commit Graph

9129 Commits

Author SHA1 Message Date
Stuart Cook
f7f411dd4e
Rollup merge of #131930 - clubby789:revision-cfg-collide, r=jieyouxu
Don't allow test revisions that conflict with built in cfgs

Fixes #128964

Sorry `@heysujal` I started working on this about 1 minute before your comment by complete coincidence 😅
2024-10-24 14:19:56 +11:00
Stuart Cook
4b02d642dd
Rollup merge of #131909 - clubby789:enum-overflow-cast, r=compiler-errors
Prevent overflowing enum cast from ICEing

Fixes #131902
2024-10-24 14:19:56 +11:00
Stuart Cook
4c0bab3192
Rollup merge of #131898 - lukas-code:ptr-cast-cleanup, r=compiler-errors
minor `*dyn` cast cleanup

Small follow-up to https://github.com/rust-lang/rust/pull/130234 to remove a redundant check and clean up comments. No functional changes.

Also, explain why casts cannot drop the principal even though coercions can, and add a test because apparently we didn't have one already.

r? `@WaffleLapkin` or `@compiler-errors`
2024-10-24 14:19:55 +11:00
Stuart Cook
ad43be310f
Rollup merge of #131756 - compiler-errors:deeply-normalize-type-err, r=lcnr
Deeply normalize `TypeTrace` when reporting type error in new solver

Normalize the values that come from the `TypeTrace` for various type mismatches.

Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe...

r? lcnr
2024-10-24 14:19:55 +11:00
Stuart Cook
9c73bcfa8d
Rollup merge of #130225 - adetaylor:rename-old-receiver, r=wesleywiser
Rename Receiver -> LegacyReceiver

As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard. Options considered included:
* HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? `@wesleywiser`
2024-10-24 14:19:53 +11:00
Michael Goulet
4217b8702d Deeply normalize type trace in type error reporting 2024-10-24 02:48:28 +00:00
clubby789
2e3091d66c Don't allow test revisions that conflict with built in cfgs 2024-10-23 18:05:27 +00:00
Josh Triplett
ecdc2441b6 "innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
2024-10-23 02:45:24 -07:00
bors
9abfcb4900 Auto merge of #132053 - matthiaskrgr:rollup-u5ds6i3, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #131707 (Run most `core::num` tests in const context too)
 - #132002 (abi/compatibility: also test Option-like types)
 - #132026 (analyse: remove unused uncanonicalized field)
 - #132031 (Optimize `Rc<T>::default`)
 - #132040 (relnotes: fix stabilizations of `assume_init`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-23 05:57:00 +00:00
Matthias Krüger
7e1dbaec13
Rollup merge of #132002 - RalfJung:abi-compat-option-like, r=compiler-errors
abi/compatibility: also test Option-like types

Adds tests for the decision [here](https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599).

Cc ``@workingjubilee``
2024-10-23 06:51:24 +02:00
Michael Goulet
febb3f7c88 Represent TraitBoundModifiers as distinct parts in HIR 2024-10-22 19:48:44 +00:00
bors
86d69c705a Auto merge of #132035 - matthiaskrgr:rollup-ty1e4q0, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #125205 (Fixup Windows verbatim paths when used with the `include!` macro)
 - #131049 (Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`)
 - #131549 (Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function)
 - #131731 (add `TestFloatParse` to `tools.rs` for bootstrap)
 - #131732 (Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES)
 - #132006 (don't stage-off to previous compiler when CI rustc is available)
 - #132022 (Move `cmp_in_dominator_order` out of graph dominator computation)
 - #132033 (compiletest: Make `line_directive` return a `DirectiveLine`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-22 14:16:37 +00:00
Matthias Krüger
457087ed29
Rollup merge of #131549 - compiler-errors:try-in-sync, r=spastorino
Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function

It's confusing to `?` a future of a result in a sync function. We have a suggestion to `.await` it if we're in an async function, but not a sync function. Note that this is the case for sync functions, at least.

Let's be a bit more vague about a fix, since it's somewhat context dependent. For example, you could block on it, or you could make your function asynchronous. 🤷
2024-10-22 15:28:41 +02:00
Adrian Taylor
8f85b90ca6 Rename Receiver -> LegacyReceiver
As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
  standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
https://github.com/rust-lang/rfcs/pull/3519
https://github.com/rust-lang/rust/issues/44874

r? @wesleywiser
2024-10-22 12:55:16 +00:00
bors
bca5fdebe0 Auto merge of #131321 - RalfJung:feature-activation, r=nnethercote
terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)

Mostly, we currently call a feature that has a corresponding `#[feature(name)]` attribute in the current crate a "declared" feature. I think that is confusing as it does not align with what "declaring" usually means. Furthermore, we *also* refer to `#[stable]`/`#[unstable]` as *declaring* a feature (e.g. in [these diagnostics](f25e5abea2/compiler/rustc_passes/messages.ftl (L297-L301))), which aligns better with what "declaring" usually means. To make things worse, the functions  `tcx.features().active(...)` and  `tcx.features().declared(...)` both exist and they are doing almost the same thing (testing whether a corresponding `#[feature(name)]`  exists) except that `active` would ICE if the feature is not an unstable lang feature. On top of this, the callback when a feature is activated/declared is called `set_enabled`, and many comments also talk about "enabling" a feature.

So really, our terminology is just a mess.

I would suggest we use "declaring a feature" for saying that something is/was guarded by a feature (e.g. `#[stable]`/`#[unstable]`), and "enabling a feature" for  `#[feature(name)]`. This PR implements that.
2024-10-22 11:02:35 +00:00
Ralf Jung
46ce5cbf33 terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it) 2024-10-22 07:37:54 +01:00
bors
f225713007 Auto merge of #132020 - workingjubilee:rollup-a8iehqg, r=workingjubilee
Rollup of 6 pull requests

Successful merges:

 - #130432 (rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972))
 - #131697 (`rt::Argument`: elide lifetimes)
 - #131807 (Always specify `llvm_abiname` for RISC-V targets)
 - #131954 (shave 150ms off bootstrap)
 - #132015 (Move const trait tests from `ui/rfcs/rfc-2632-const-trait-impl` to `ui/traits/const-traits`)
 - #132017 (Update triagebot.toml)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-22 05:49:18 +00:00
Jubilee
1ea4eabb81
Rollup merge of #132015 - compiler-errors:move-const-trait-tests, r=fee1-dead
Move const trait tests from `ui/rfcs/rfc-2632-const-trait-impl` to `ui/traits/const-traits`

I found the old test directory to be somewhat long to name, and I don't think it's necessary to put an experimental implementation's tests under an rfc which is closed.

r? fee1-dead

Breaking this out of #131985 so that PR doesn't touch 300 files.
2024-10-21 20:32:02 -07:00
Jubilee
763fbf8a90
Rollup merge of #131697 - ShE3py:rt-arg-lifetimes, r=Amanieu
`rt::Argument`: elide lifetimes

`@rustbot` label +C-cleanup
2024-10-21 20:32:01 -07:00
Jubilee
fe2cbbd2d5
Rollup merge of #130432 - azhogin:azhogin/regparm, r=workingjubilee,pnkfelix
rust_for_linux: -Zregparm=<N> commandline flag for X86 (#116972)

Command line flag `-Zregparm=<N>` for X86 (32-bit) for rust-for-linux: https://github.com/rust-lang/rust/issues/116972
Implemented in the similar way as fastcall/vectorcall support (args are marked InReg if fit).
2024-10-21 20:32:00 -07:00
bors
1de57a5ce9 Auto merge of #129935 - RalfJung:unsupported_calling_conventions, r=compiler-errors
make unsupported_calling_conventions a hard error

This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) even when the lint was originally added.

This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.)

Fixes https://github.com/rust-lang/rust/pull/87678
2024-10-22 03:24:40 +00:00
Michael Goulet
e91267f3f0 Move tests 2024-10-22 00:03:09 +00:00
Ralf Jung
d567fcc301 abi/compatibility: also test Option-like types 2024-10-21 18:24:45 +01:00
Matthias Krüger
780a8c32cc
Rollup merge of #132001 - lcnr:stabilize-coherence-again, r=compiler-errors
fix coherence error for very large tuples™

see https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/diesel.20error for an in-depth explanation of this issue. We once again specialize `NormalizesTo` goals to avoid the impact of erasing their expected term.

fixes #131969

r? `@compiler-errors`
2024-10-21 18:11:22 +02:00
Matthias Krüger
4aa07a7867
Rollup merge of #131999 - jieyouxu:unit-bindings, r=WaffleLapkin
Improve test coverage for `unit_bindings` lint

Follow-up to #112380, apparently at the time I didn't add much of any test coverage outside of just "generally works as intended on the test suites and in the crater run".

r? compiler
2024-10-21 18:11:22 +02:00
Matthias Krüger
a9da2be010
Rollup merge of #131991 - jannden:issue-98565-test, r=jieyouxu
test: Add test for trait in FQS cast, issue #98565

Closes #98565 by adding a test to check for diagnostics when the built-in type `str` is used in a cast where a trait is expected.
2024-10-21 18:11:21 +02:00
Matthias Krüger
20b1dadf92
Rollup merge of #130350 - RalfJung:strict-provenance, r=dtolnay
stabilize Strict Provenance and Exposed Provenance APIs

Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs:
```rust
// core::ptr
pub const fn without_provenance<T>(addr: usize) -> *const T;
pub const fn dangling<T>() -> *const T;
pub const fn without_provenance_mut<T>(addr: usize) -> *mut T;
pub const fn dangling_mut<T>() -> *mut T;
pub fn with_exposed_provenance<T>(addr: usize) -> *const T;
pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T;

impl<T: ?Sized> *const T {
    pub fn addr(self) -> usize;
    pub fn expose_provenance(self) -> usize;
    pub fn with_addr(self, addr: usize) -> Self;
    pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}

impl<T: ?Sized> *mut T {
    pub fn addr(self) -> usize;
    pub fn expose_provenance(self) -> usize;
    pub fn with_addr(self, addr: usize) -> Self;
    pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}

impl<T: ?Sized> NonNull<T> {
    pub fn addr(self) -> NonZero<usize>;
    pub fn with_addr(self, addr: NonZero<usize>) -> Self;
    pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self;
}
```

I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort.

There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](https://github.com/rust-lang/rust/issues/130351) feature since I didn't want this PR to have an even bigger FCP. ;)

`@rust-lang/opsem` Would be great to get some feedback on the docs here. :)
Nominating for `@rust-lang/libs-api.`

Part of https://github.com/rust-lang/rust/issues/95228.

[FCP comment](https://github.com/rust-lang/rust/pull/130350#issuecomment-2395114536)
2024-10-21 18:11:19 +02:00
lcnr
919b61a6f4 don't bail when encountering many placeholders 2024-10-21 17:51:43 +02:00
lcnr
b64b25b99e normalizes-to disable infer var check 2024-10-21 16:25:42 +02:00
Ralf Jung
56ee492a6e move strict provenance lints to new feature gate, remove old feature gates 2024-10-21 15:22:17 +01:00
许杰友 Jieyou Xu (Joe)
70ce711098 unit_bindings: improve test coverage 2024-10-21 21:33:33 +08:00
Jan Cibulka
d5cfcc71e8
test: Add test for trait in FQS cast, issue #98565 2024-10-21 11:45:19 +03:00
bors
3e33bda032 Auto merge of #130628 - workingjubilee:clean-up-result-ffi-guarantees, r=RalfJung
Finish stabilization of `result_ffi_guarantees`

The internal linting has been changed, so all that is left is making sure we stabilize what we want to stabilize.
2024-10-21 08:38:45 +00:00
Jubilee Young
7baf06680c lang: Strengthen RFC 3391 guarantees to match T-lang consensus 2024-10-21 00:43:36 -07:00
bors
93742bd782 Auto merge of #131988 - matthiaskrgr:rollup-tx173wn, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #126588 (Added more scenarios where comma to be removed in the function arg)
 - #131728 (bootstrap: extract builder cargo to its own module)
 - #131968 (Rip out old effects var handling code from traits)
 - #131981 (Remove the `BoundConstness::NotConst` variant)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-21 06:13:34 +00:00
Matthias Krüger
9ff4dab396
Rollup merge of #126588 - linyihai:trim-extra-comma, r=petrochenkov
Added more scenarios where comma to be removed in the function arg

This is an attempt to address the problem methion in https://github.com/rust-lang/rust/issues/106304#issuecomment-1837273666.

Copy the annotation to explain the fix

If the next Error::Extra ("next") doesn't next to current ("current")

```
fn foo(_: (), _: u32) {}
- foo("current", (), 1u32, "next")
+ foo((), 1u32)
```

If the previous error is not a `Error::Extra`, then do not trim the next comma

```
- foo((), "current", 42u32, "next")
+ foo((), 42u32)
```

Frankly, this is a fix from a test case and may not cover all scenarios
2024-10-21 07:01:36 +02:00
bors
f2ba41113d Auto merge of #130950 - compiler-errors:yeet-eval, r=BoxyUwU
Continue to get rid of `ty::Const::{try_}eval*`

This PR mostly does:

* Removes all of the `try_eval_*` and `eval_*` helpers from `ty::Const`, and replace their usages with `try_to_*`.
* Remove `ty::Const::eval`.
* Rename `ty::Const::normalize` to `ty::Const::normalize_internal`. This function is still used in the normalization code itself.
* Fix some weirdness around the `TransmuteFrom` goal.

I'm happy to split it out further; for example, I could probably land the first part which removes the helpers, or the changes to codegen which are more obvious than the changes to tools.

r? BoxyUwU

Part of https://github.com/rust-lang/rust/issues/130704
2024-10-21 03:46:28 +00:00
bors
7ed1a51b25 Auto merge of #131980 - matthiaskrgr:rollup-iy5nw71, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #131814 (`optimize` attribute applied to things other than methods/functions/c…)
 - #131927 (Check for filecheck directives in files marked `skip-filecheck`)
 - #131967 (Remove `lower_mono_bounds`)
 - #131973 (fix(rustdoc-json-types): document rustc-hash feature)
 - #131976 (feat(rustdoc-json-types): mark simple enums as copy)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-20 21:40:21 +00:00
Matthias Krüger
2a9b6d9626
Rollup merge of #131814 - Borgerr:misapplied-optimize-attribute, r=jieyouxu
`optimize` attribute applied to things other than methods/functions/c…

…losures gives an error (#128488)

Duplicate of #128943, which I had accidentally closed when rebasing.

cc. `@jieyouxu` `@compiler-errors` `@nikomatsakis` `@traviscross` `@pnkfelix.`
2024-10-20 21:04:13 +02:00
bors
662180b34d Auto merge of #131949 - Noratrieb:fxhashup-thanks-alona, r=WaffleLapkin
Update rustc-hash to version 2 but again

it's like #129533 but not closed by bors and rebased

r? WaffleLapkin meow
2024-10-20 19:01:54 +00:00
Lukas Markeffsky
46cc5e9e96 elaborate why dropping principal in *dyn casts is non-trivial 2024-10-20 17:54:04 +02:00
Matthias Krüger
6d43de643e
Rollup merge of #131843 - workingjubilee:thaw-impossible-reprs, r=lukas-code
compiler: Error on layout of enums with invalid reprs

Surprising no one, the ICEs with the same message have the same root cause.

Invalid reprs can reach layout computation for various reasons. For instance, the compiler may want to use its layout computations to discern if a combination of layout-affecting attributes results in a valid type to begin with by e.g. computing its size. When the input is bad, return an error reflecting that the answer to the question is not a useful one.
2024-10-20 16:54:10 +02:00
Matthias Krüger
7b714d4735
Rollup merge of #121560 - Noratrieb:stop-lint-macro-nonsense, r=jieyouxu
Allow `#[deny]` inside `#[forbid]` as a no-op

Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense.

Except it doesn't, because macros. Macros may reasonably use `#[deny]` (or `#[warn]` for an allow-by-default lint) in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint!

By making it a warning instead, we remove the problem with the macro, which is now nothing as warnings are suppressed in macro expanded code, while still telling users that something is up.

fixes #121483
2024-10-20 16:54:08 +02:00
ash
080103f1ed misapplied optimize attribute throws a compilation error (#128488) 2024-10-20 08:34:15 -06:00
Ralf Jung
de3cbf3c56 make unsupported_calling_conventions a hard error 2024-10-20 15:22:21 +02:00
Lin Yihai
f1070825bb Added more scenarios where commas need to be removed 2024-10-20 17:14:53 +08:00
Jubilee Young
9f4c9155d4 compiler: Reject impossible reprs during enum layout 2024-10-20 02:12:58 -07:00
Jubilee Young
68d1fd9427 compiler: pre-move code for fixing enum layout ICEs 2024-10-20 02:09:22 -07:00
Noratrieb
0c8d81b4df Stop relying on hashmap iteration for unused macro rules arms 2024-10-20 00:12:52 -07:00
Noratrieb
3efd5926f6 Stop relying on hashmap iteration for hir stat printing
Just because the code says it's OK does not mean that it actually is OK.
Nodes with the same total size were not sorted, their order relied on
hashmap iteration.
2024-10-20 00:12:52 -07:00