| Age | Commit message (Collapse) | Author | Lines |
|---|
|
remove unnecessary string searchings for checking if function arguments have `&` and `&mut`
|
|
|
|
|
|
|
|
|
|
|
|
r=estebank
Only point out a single function parameter if we have a single arg incompatibility
Fixes #99635
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
make vtable pointers entirely opaque
This implements the scheme discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/338: vtable pointers should be considered entirely opaque and not even readable by Rust code, similar to function pointers.
- We have a new kind of `GlobalAlloc` that symbolically refers to a vtable.
- Miri uses that kind of allocation when generating a vtable.
- The codegen backends, upon encountering such an allocation, call `vtable_allocation` to obtain an actually dataful allocation for this vtable.
- We need new intrinsics to obtain the size and align from a vtable (for some `ptr::metadata` APIs), since direct accesses are UB now.
I had to touch quite a bit of code that I am not very familiar with, so some of this might not make much sense...
r? `@oli-obk`
|
|
|
|
r=spastorino
Use `typeck_results` to avoid duplicate `ast_ty_to_ty` call
Comes with a bunch of improvements in spans :heart_eyes:
|
|
|
|
|
|
Revert "Highlight conflicting param-env candidates"
This reverts #98794, commit 08135254dcf22be0d5661ea8f75e703b29a83514.
Seems to have caused an incremental compilation bug. The root cause of the incr comp bug is somewhat unrelated but is triggered by this PR, so I don't feel comfortable with having this PR in the codebase until it can be investigated further. Fixes #99233.
|
|
This reverts commit 08135254dcf22be0d5661ea8f75e703b29a83514.
|
|
Migrate half of the `rustc_passes::check_attr` diagnostics to using
diagnostic derives and being translatable.
|
|
Fix duplicated type annotation suggestion
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes #93506 .
|
|
Mention similarly named associated type even if it's not clearly in supertrait
Due to query cycle avoidance, we sometimes restrict the candidates in `complain_about_assoc_type_not_found` too much so that we can't detect typo replacements from just supertraits.
This creates a more general note of the existence of a similarly named associated type from _all_ visible traits when possible.
Fixes #55673
|
|
|
|
|
|
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes #93506 .
|
|
Methods are defined within the context of a struct and their first parameter is always self
Associated functions don’t take self as a parameter
modified: compiler/rustc_typeck/src/check/method/suggest.rs
modified: src/test/ui/auto-ref-slice-plus-ref.stderr
modified: src/test/ui/block-result/issue-3563.stderr
modified: src/test/ui/issues/issue-28344.stderr
modified: src/test/ui/suggestions/dont-suggest-pin-array-dot-set.stderr
modified: src/test/ui/suggestions/suggest-methods.stderr
modified: src/test/ui/traits/trait-upcasting/subtrait-method.stderr
|
|
Track implicit `Sized` obligations in type params
When we evaluate `ty::GenericPredicates` we introduce the implicit
`Sized` predicate of type params, but we do so with only the `Predicate`
its `Span` as context, we don't have an `Obligation` or
`ObligationCauseCode` we could influence. To try and carry this
information through, we add a new field to `ty::GenericPredicates` that
tracks both which predicates come from a type param and whether that
param has any bounds already (to use in suggestions).
We also suggest adding a `?Sized` bound if appropriate on E0599.
Address part of #98539.
|
|
r=michaelwoerister
Highlight conflicting param-env candidates
This could probably be further improved by noting _why_ equivalent param-env candidates (modulo regions) leads to ambiguity.
Fixes #98786
|
|
|
|
Suggest adding a `?Sized` bound if appropriate on E0599 by inspecting
the HIR Generics. (Fix #98539)
|
|
|
|
Enable MIR inlining
Continuation of https://github.com/rust-lang/rust/pull/82280 by `@wesleywiser.`
#82280 has shown nice compile time wins could be obtained by enabling MIR inlining.
Most of the issues in https://github.com/rust-lang/rust/issues/81567 are now fixed,
except the interaction with polymorphization which is worked around specifically.
I believe we can proceed with enabling MIR inlining in the near future
(preferably just after beta branching, in case we discover new issues).
Steps before merging:
- [x] figure out the interaction with polymorphization;
- [x] figure out how miri should deal with extern types;
- [x] silence the extra arithmetic overflow warnings;
- [x] remove the codegen fulfilment ICE;
- [x] remove the type normalization ICEs while compiling nalgebra;
- [ ] tweak the inlining threshold.
|
|
Rollup of 5 pull requests
Successful merges:
- #97249 (`<details>`/`<summary>` UI fixes)
- #98418 (Allow macOS to build LLVM as shared library)
- #98460 (Use CSS variables to handle theming)
- #98497 (Improve some inference diagnostics)
- #98708 (rustdoc: fix 98690 Panic if invalid path for -Z persist-doctests)
Failed merges:
- #98761 (more `need_type_info` improvements)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
trait predicate
|
|
|
|
|
|
|
|
|
|
Do not access HIR to check impl wf.
r? `@ghost`
|
|
Perform coherence checking per impl.
r? `@ghost`
|
|
|
|
r=compiler-errors
Point to type parameter definition when not finding variant, method and associated item
fixes #77391
|
|
|
|
|
|
use `def_ident_span` , `body_owner_def_id` instead of `in_progress_typeck_results`, `guess_head_span`
use `body_id.owner` directly
add description to label
|
|
|
|
|
