Commit Graph

118 Commits

Author SHA1 Message Date
Michael Goulet
8b7b8e5f56 Hack out effects support for old solver 2024-10-28 21:42:14 +00:00
Matthias Krüger
21c57f5490
Rollup merge of #128391 - cafce25:issue-128390, r=lcnr
Change orphan hint from "only" to "any uncovered type inside..."

Fix #128390
2024-10-17 12:07:19 +02:00
Folkert de Vries
10aa255541 improve error messages for C-cmse-nonsecure-entry functions 2024-10-14 22:32:32 +02:00
bors
f4966590d8 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
Michael Goulet
36076ecdc7 Clarify implicit captures for RPITIT 2024-10-10 11:46:51 -07:00
Michael Goulet
e3a0da1863 Remove unnamed field feature 2024-10-01 13:55:46 -04:00
Jonathan Birk
b89c6204da Make new information notes instead of labels 2024-09-26 17:17:11 +00:00
León Orell Valerian Liehr
01a063f9df
Compiler: Rename "object safe" to "dyn compatible" 2024-09-25 13:26:48 +02:00
Michael Goulet
d72d44d8ed
Rollup merge of #129629 - compiler-errors:rtn-in-path, r=jackh726
Implement Return Type Notation (RTN)'s path form in where clauses

Implement return type notation (RTN) in path position for where clauses. We already had RTN in associated type position ([e.g.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=627a4fb8e2cb334863fbd08ed3722c09)), but per [the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#where-rtn-can-be-used-for-now):

> As a standalone type, RTN can only be used as the Self type of a where-clause [...]

Specifically, in order to enable code like:

```rust
trait Foo {
    fn bar() -> impl Sized;
}

fn is_send(_: impl Send) {}

fn test<T>()
where
    T: Foo,
    T::bar(..): Send,
{
    is_send(T::bar());
}
```

* In the resolver, when we see a `TyKind::Path` whose final segment is `GenericArgs::ParenthesizedElided` (i.e. `(..)`), resolve that path in the *value* namespace, since we're looking for a method.
* When lowering where clauses in HIR lowering, we first try to intercept an RTN self type via `lower_ty_maybe_return_type_notation`. If we find an RTN type, we lower it manually in a way that respects its higher-ranked-ness (see below) and resolves to the corresponding RPITIT. Anywhere else, we'll emit the same "return type notation not allowed in this position yet" error we do when writing RTN in every other position.
* In `resolve_bound_vars`, we add some special treatment for RTN types in where clauses. Specifically, we need to add new lifetime variables to our binders for the early- and late-bound vars we encounter on the method. This implements the higher-ranked desugaring [laid out in the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds).

This PR also adds a bunch of tests, mostly negative ones (testing error messages).

In a follow-up PR, I'm going to mark RTN as no longer incomplete, since this PR basically finishes the impl surface that we should initially stabilize, and the RFC was accepted.

cc [RFC 3654](https://github.com/rust-lang/rfcs/pull/3654) and https://github.com/rust-lang/rust/issues/109417
2024-09-21 15:18:56 -04:00
bors
1d68e6dd1d Auto merge of #127546 - workingjubilee:5-level-paging-exists, r=saethlin
Correct outdated object size limit

The comment here about 48 bit addresses being enough was written in 2016 but was made incorrect in 2019 by 5-level paging, and then persisted for another 5 years before being noticed and corrected.

The bolding of the "exclusive" part is merely to call attention to something I missed when reading it and doublechecking the math.

try-job: i686-msvc
try-job: test-various
2024-09-21 16:20:10 +00:00
Michael Goulet
7c8e281f73 Flesh out some TODOs 2024-09-20 22:18:57 -04:00
Michael Goulet
19881b5a5a Conditionally allow lowering RTN (..) in paths 2024-09-20 22:18:57 -04:00
Jubilee Young
325af25c94 TL note: current means target 2024-09-20 10:02:14 -07:00
Obei Sideg
74cab947f7
Disallow hidden references to mutable static 2024-09-13 13:33:43 +03:00
Jonathan Birk
ca94dd5bea Add more information link to orphan impls 2024-08-11 10:50:07 +00:00
Jonathan Birk
9ce811cd00
Change orphan hint from "only" to "any uncovered type inside..." 2024-07-30 14:55:27 +02:00
Bryanskiy
f2f9aab380 Delegation: support generics for delegation from free functions 2024-07-29 20:04:55 +03:00
León Orell Valerian Liehr
3c8b108512
Inside eager ty aliases on unresolved assoc tys suggest fully qualifying instead of restricting their self ty 2024-07-23 01:26:24 +02:00
León Orell Valerian Liehr
898448ca58
HIR ty lowering: Refactor the way the projectee ("QSelf") gets passed to diagnostics 2024-07-23 01:23:54 +02:00
bors
9629b90b3f Auto merge of #127722 - BoxyUwU:new_adt_const_params_limitations, r=compiler-errors
Forbid borrows and unsized types from being used as the type of a const generic under `adt_const_params`

Fixes #112219
Fixes #112124
Fixes #112125

### Motivation

Currently the `adt_const_params` feature allows writing `Foo<const N: [u8]>` this is entirely useless as it is not possible to write an expression which evaluates to a type that is not `Sized`. In order to actually use unsized types in const generics they are typically written as `const N: &[u8]` which *is* possible to provide a value of.

Unfortunately allowing the types of const parameters to contain references is non trivial (#120961) as it introduces a number of difficult questions about how equality of references in the type system should behave. References in the types of const generics is largely only useful for using unsized types in const generics.

This PR introduces a new feature gate `unsized_const_parameters` and moves support for `const N: [u8]` and `const N: &...` from `adt_const_params` into it. The goal here hopefully is to experiment with allowing `const N: [u8]` to work without references and then eventually completely forbid references in const generics.

Splitting this out into a new feature gate means that stabilization of `adt_const_params` does not have to resolve #120961 which is the only remaining "big" blocker for the feature. Remaining issues after this are a few ICEs and naming bikeshed for `ConstParamTy`.

### Implementation

The implementation is slightly subtle here as we would like to ensure that a stabilization of `adt_const_params` is forwards compatible with any outcome of `unsized_const_parameters`. This is inherently tricky as we do not support unstable trait implementations and we determine whether a type is valid as the type of a const parameter via a trait bound.

There are a few constraints here:
- We would like to *allow for the possibility* of adding a `Sized` supertrait to `ConstParamTy` in the event that we wind up opting to not support unsized types and instead requiring people to write the 'sized version', e.g. `const N: [u8; M]` instead of `const N: [u8]`.
- Crates should be able to enable `unsized_const_parameters` and write trait implementations of `ConstParamTy` for `!Sized` types without downstream crates that only enable `adt_const_params` being able to observe this (required for std to be able to `impl<T> ConstParamTy for [T]`

Ultimately the way this is accomplished is via having two traits (sad), `ConstParamTy` and `UnsizedConstParamTy`. Depending on whether `unsized_const_parameters` is enabled or not we change which trait is used to check whether a type is allowed to be a const parameter.

Long term (when stabilizing `UnsizedConstParamTy`) it should be possible to completely merge these traits (and derive macros), only having a single `trait ConstParamTy` and `macro ConstParamTy`.

Under `adt_const_params` it is now illegal to directly refer to `ConstParamTy` it is only used as an internal impl detail by `derive(ConstParamTy)` and checking const parameters are well formed. This is necessary in order to ensure forwards compatibility with all possible future directions for `feature(unsized_const_parameters)`.

Generally the intuition here should be that `ConstParamTy` is the stable trait that everything uses, and `UnsizedConstParamTy` is that plus unstable implementations (well, I suppose `ConstParamTy` isn't stable yet :P).
2024-07-21 05:36:21 +00:00
Matthias Krüger
a2c99cf87c
Rollup merge of #127966 - oli-obk:structured_diag, r=compiler-errors
Use structured suggestions for unconstrained generic parameters on impl blocks

I did not deduplicate with `UnusedGenericParameter`, because in contrast to type declarations, just using a generic parameter in an impl isn't enough, it must be used with the right variance and not just as part of a projection.
2024-07-19 20:03:57 +02:00
Matthias Krüger
3b20150b48
Rollup merge of #127814 - folkertdev:c-cmse-nonsecure-call-error-messages, r=oli-obk
`C-cmse-nonsecure-call`: improved error messages

tracking issue: #81391
issue for the error messages (partially implemented by this PR): #81347
related, in that it also deals with CMSE: https://github.com/rust-lang/rust/pull/127766

When using the `C-cmse-nonsecure-call` ABI, both the arguments and return value must be passed via registers. Previously, when violating this constraint, an ugly LLVM error would be shown. Now, the rust compiler itself will print a pretty message and link to more information.
2024-07-19 20:03:56 +02:00
Oli Scherer
a0db06bdeb Use structured suggestions for unconstrained generic parameters on impl blocks 2024-07-19 14:21:56 +00:00
Folkert
c2894a4297
improve error reporting 2024-07-18 14:32:10 +02:00
Folkert
7b63734961
move CMSE validation to hir_analysis 2024-07-18 12:42:40 +02:00
Michael Goulet
c02d0de871 Account for structs that have unused params in nested types in fields 2024-07-17 21:12:12 -04:00
Michael Goulet
a0a251a688 Account for self ty alias 2024-07-17 16:48:17 -04:00
Michael Goulet
3716a3fd31 Mention that type parameters are used recursively 2024-07-17 15:57:38 -04:00
Boxy
d0c11bf6e3 Split part of adt_const_params into unsized_const_params 2024-07-17 11:01:29 +01:00
Boxy
42cc42b942 Forbid !Sized types and references 2024-07-17 11:01:29 +01:00
Oli Scherer
9e7918f70e Remove another StructuredDiag impl 2024-07-08 19:29:55 +00:00
Oli Scherer
0d54fe0d02 Remove a use of StructuredDiag, which is incompatible with automatic error tainting and error translations 2024-07-04 12:20:51 +00:00
Deadbeef
34ae56de35 Make feature(effects) require -Znext-solver 2024-06-30 17:08:10 +00:00
Guillaume Gomez
3ed2cd74b5
Rollup merge of #126686 - fmease:dump-preds-n-item-bounds, r=compiler-errors
Add `#[rustc_dump_{predicates,item_bounds}]`

Conflicts with #126668.

As discussed
r? compiler-errors CC ``@fee1-dead``
2024-06-22 12:57:19 +02:00
Michael Goulet
ffd72b1700 Fix remaining cases 2024-06-21 19:00:18 -04:00
León Orell Valerian Liehr
bc12972bcd
Slightly refactor the dumping of HIR analysis data 2024-06-20 20:31:32 +02:00
bors
bbe9a9c20b Auto merge of #126319 - workingjubilee:rollup-lendnud, r=workingjubilee
Rollup of 16 pull requests

Successful merges:

 - #123374 (DOC: Add FFI example for slice::from_raw_parts())
 - #124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
 - #125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
 - #125980 (Nvptx remove direct passmode)
 - #126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
 - #126210 (docs(core): make more const_ptr doctests assert instead of printing)
 - #126249 (Simplify `[T; N]::try_map` signature)
 - #126256 (Add {{target}} substitution to compiletest)
 - #126263 (Make issue-122805.rs big endian compatible)
 - #126281 (set_env: State the conclusion upfront)
 - #126286 (Make `storage-live.rs` robust against rustc internal changes.)
 - #126287 (Update a cranelift patch file for formatting changes.)
 - #126301 (Use `tidy` to sort crate attributes for all compiler crates.)
 - #126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
 - #126310 (Migrate run make prefer rlib)
 - #126314 (fix RELEASES: we do not support upcasting to auto traits)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-12 11:10:50 +00:00
Oli Scherer
0bc2001879 Require any function with a tait in its signature to actually constrain a hidden type 2024-06-12 08:53:59 +00:00
León Orell Valerian Liehr
c59a2b2746
Cleanup: HIR ty lowering: Consolidate assoc item access checking 2024-06-04 23:13:16 +02:00
León Orell Valerian Liehr
34c56c45cf
Rename HIR TypeBinding to AssocItemConstraint and related cleanup 2024-05-30 22:52:33 +02:00
León Orell Valerian Liehr
7faa879486
Pattern types: Prohibit generic args on const params 2024-05-11 16:12:43 +02:00
bors
f5355b93ba Auto merge of #124356 - fmease:fewer-magic-numbers-in-names, r=lcnr
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful

**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:

> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.

I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?

The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.

Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.

r? lcnr or compiler
2024-05-01 00:04:36 +00:00
León Orell Valerian Liehr
2a1d748254
Replace item names containing an error code with something more meaningful
or inline such functions if useless.
2024-04-30 22:27:19 +02:00
León Orell Valerian Liehr
951e902562
Normalize trait ref before orphan check & consider ty params in alias types to be uncovered 2024-04-30 21:54:54 +02:00
Michael Goulet
57085a06d9 Explicitly mention Self 2024-04-20 11:39:43 -04:00
Michael Goulet
ac7651ccaf More polishing 2024-04-15 16:45:48 -04:00
Michael Goulet
52c6b101ea Use a path instead of an ident (and stop manually resolving) 2024-04-15 16:45:26 -04:00
Michael Goulet
ce8961039e Some ordering and duplication checks 2024-04-15 16:45:26 -04:00
Michael Goulet
42ba57c013 Validation and other things 2024-04-15 16:45:01 -04:00
Michael Goulet
2d813547bf Move check to wfcheck 2024-04-09 12:17:34 -04:00