Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes#56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
Implement basic input validation for built-in attributes
Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").
For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.
NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
rustc: Remove platform intrinsics crate
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
Point at match discriminant on type error in match arm pattern
```
error[E0308]: mismatched types
--> src/main.rs:5:9
|
4 | let temp: usize = match a + b {
| ----- this expression has type `usize`
5 | Ok(num) => num,
| ^^^^^^^ expected usize, found enum `std::result::Result`
|
= note: expected type `usize`
found type `std::result::Result<_, _>`
```
Fix#57279.
use structured suggestion for method calls
Furthermore, don't suggest calling the method if it is part of a place
expression, as this is invalid syntax.
I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice.
The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas?
r? @estebank
Improve type mismatch error messages
Closes#56115.
Replace "integral variable" with "integer" and replace "floating-point variable" with "floating-point number" to make the message less confusing.
TODO the book and clippy needs to be changed accordingly later.
r? @varkor
privacy: Use common `DefId` visiting infrastructure for all privacy visitors
One repeating pattern in privacy checking is going through a type, visiting all `DefId`s inside it and doing something with them.
This is the case because visibilities and reachabilities are attached to `DefId`s.
Previously various privacy visitors visited types slightly differently using their own methods, with most recently written `TypePrivacyVisitor` being the "gold standard".
This mostly worked okay, but differences could manifest in overly conservative reachability analysis, some errors being reported twice, some private-in-public lints (not errors) being wrongly reported or not reported.
This PR does something that I wanted to do since https://github.com/rust-lang/rust/pull/32674#discussion_r58291608 - factoring out the common visiting logic!
Now all the common logic is contained in `struct DefIdVisitorSkeleton`, with specific privacy visitors deciding only what to do with visited `DefId`s (via `trait DefIdVisitor`).
A bunch of cleanups is also applied in the process.
This area is somewhat tricky due to lots of easily miss-able details, but thankfully it's was well covered by tests in https://github.com/rust-lang/rust/pull/46083 and previous PRs, so I'm relatively sure in the refactoring correctness.
Fixes https://github.com/rust-lang/rust/pull/56837#discussion_r241962239 in particular.
Also this will help with implementing https://github.com/rust-lang/rust/issues/48054.
make non_camel_case_types an early lint
This allows us to catch these kinds of style violations much earlier, as evidenced by the large number of tests that had to be updated for this change.
Contexually dependent error message for E0424 when value is assigned to "self"
This is an improvement for pull request #54495 referencing issue #54369. If the "self" keyword is assigned a value as though it were a valid identifier, it will now report:
```
let self = "self";
^^^^ `self` value is a keyword and may not be bound to variables or shadowed
```
instead of
```
let self = "self";
^^^^ `self` value is a keyword only available in methods with `self` parameter
```
If anyone has a better idea for what the error should be I'd be happy to modify it appropriately.
