| Age | Commit message (Collapse) | Author | Lines |
|---|
|
avoid unnecessary collect()
|
|
Don't show suggestion if slice pattern is not top-level
Close #120605
Don't show suggestion to add slicing (`[..]`) if the slice pattern is enclosed by struct like `Struct { a: [] }`.
For example, current rustc makes a suggestion as a comment. However, the pattern `a: []` is wrong, not scrutinee `&self.a`.
In this case, the structure type `a: Vec<Struct>` and the pattern `a: []` are different so I think the pattern should be fixed, not the scrutinee.
If the parent of the pattern that was the target of the error is a structure, I made the compiler not show a suggestion.
```rs
pub struct Struct {
a: Vec<Struct>,
}
impl Struct {
pub fn test(&self) {
if let [Struct { a: [] }] = &self.a {
// ^^^^^^^^^^^^^^^^^^ ------- help: consider slicing here: `&self.a[..]`
println!("matches!")
}
}
}
```
Note:
* ~~I created `PatInfo.history` to store parent-child relationships for patterns, but this may be inefficient.~~
* I use two fields `parent_kind` and `current_kind` instead of vec. It may not performance issue.
* Currently only looking at direct parents, but may need to look at deeper ancestry.
|
|
|
|
|
|
Move check-cfg diagnostic logic into a separate file
as well as adding some triagebot mentions (for me) for check-cfg related files.
``@rustbot`` label +F-check-cfg
|
|
Register LLVM handlers for bad-alloc / OOM
LLVM's default bad-alloc handler may throw if exceptions are enabled,
and `operator new` isn't hooked at all by default. Now we register our
own handler that prints a message similar to fatal errors, then aborts.
We also call the function that registers the C++ `std::new_handler`.
Fixes #121305
Cc llvm/llvm-project#85281
r? ``@nikic``
|
|
r=oli-obk,wesleywiser
Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? `@dtolnay`
|
|
|
|
osiewicz:metadata-register-crate-store-crate-name-in-profile, r=Nadrieril
rustc-metadata: Store crate name in self-profile of metadata_register_crate
When profiling a build of Zed, I found myself in need of names of crates that take the longest to register in downstream crates.
|
|
Remove obsolete parameter `speculative` from `instantiate_poly_trait_ref`
In #122527 I totally missed that `speculative` has become obsolete with the removal of `hir_trait_to_predicates` / due to #113671.
Fixes #114635.
r? `@compiler-errors`
|
|
Delegation: fix ICE on duplicated associative items
Currently, functions delegation is only supported for delegation items with early resolved paths e.g. free functions and trait methods. During name resolution, information about function signatures is collected, including the number of parameters and whether there are self arguments. This information is then used when lowering from a delegation item into a regular function(`rustc_ast_lowering/src/delegation.rs`). The signature is usually inherited from path resolution id(`path_id`). However, in the case of trait impls `path_id` and `item_id` may be different:
```rust
trait Trait {
fn foo(&self) -> u32 { 0 }
}
struct S;
mod to_reuse {
use crate::S;
pub fn foo(_: &S) -> u32 { 0 }
}
impl Trait for S {
reuse to_reuse::foo { self }
//~^ The signature should be inherited from item id instead of resolution id
}
```
Let's now consider an example from [issue](https://github.com/rust-lang/rust/issues/119920). Due to duplicated associative elements partial resolution for one of them will not be recorded:
https://github.com/rust-lang/rust/blob/9023f908cfbe7a475f369717a61cb8eb865cfd25/compiler/rustc_resolve/src/late.rs#L3153-L3162
Which leads to an incorrect `is_in_trait_impl`
https://github.com/rust-lang/rust/blob/9023f908cfbe7a475f369717a61cb8eb865cfd25/compiler/rustc_ast_lowering/src/item.rs#L981-L986
Which leads to an incorrect id for signature inheritance
https://github.com/rust-lang/rust/blob/9023f908cfbe7a475f369717a61cb8eb865cfd25/compiler/rustc_ast_lowering/src/delegation.rs#L99-L105
Which lead to an ICE from original issue.
This patch fixes wrong `is_in_trait_impl` calculation.
fixes https://github.com/rust-lang/rust/issues/119920
|
|
Split refining_impl_trait lint into _reachable, _internal variants
As discussed in https://github.com/rust-lang/rust/issues/119535#issuecomment-1909352040:
> We discussed this today in triage and developed a consensus to:
>
> * Add a separate lint against impls that refine a return type defined with RPITIT even when the trait is not crate public.
> * Place that in a lint group along with the analogous crate public lint.
> * Create an issue to solicit feedback on these lints (or perhaps two separate ones).
> * Have the warnings displayed with each lint reference this issue in a similar manner to how we do that today with the required `Self: '0'` bound on GATs.
> * Make a note to review this feedback on 2-3 release cycles.
This points users to https://github.com/rust-lang/rust/issues/121718 to leave feedback.
|
|
gvozdvmozgu:fix-attribute-validation-associated-items, r=fmease
fix attribute validation on associated items in traits
#121537, fixed attribute validation on associated items in traits
|
|
Add `wasm_c_abi` `future-incompat` lint
This is a warning that will tell users to update to `wasm-bindgen` v0.2.88, which supports spec-compliant C ABI.
The idea is to prepare for a future where Rust will switch to the spec-compliant C ABI by default; so not to break everyone's world, this warning is introduced.
Addresses #71871.
|
|
When profiling a build of Zed, I found myself in need of names of crates that take the longest to register in downstream crates.
|
|
|
|
sync_cg_clif-2024-03-16
|
|
Use `MAP_PRIVATE` (not unsound-prone `MAP_SHARED`)
Solves https://github.com/rust-lang/rust/issues/122262
|
|
|
|
Stop walking the bodies of statics for reachability, and evaluate them instead
cc `@saethlin` `@RalfJung`
cc #119214
This reuses the `DefIdVisitor` from `rustc_privacy`, because they basically try to do the same thing.
This PR's changes can probably be extended to constants, too, but let's tackle that separately, it's likely more involved.
|
|
r=compiler-errors,petrochenkov
`f16` and `f128` step 3: compiler support & feature gate
Continuation of https://github.com/rust-lang/rust/pull/121841, another portion of https://github.com/rust-lang/rust/pull/114607
This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed).
If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes.
Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step.
Tracking issue: https://github.com/rust-lang/rust/issues/116909
r? `@compiler-errors`
cc `@Nilstrieb`
`@rustbot` label +F-f16_and_f128
|
|
|
|
The bad-alloc installer was incorrectly asserting that the other handler
isn't set yet, instead of checking its own, but we can avoid that by
changing the order we install them.
Ref: https://github.com/llvm/llvm-project/issues/83040
|
|
|
|
LLVM's default bad-alloc handler may throw if exceptions are enabled,
and `operator new` isn't hooked at all by default. Now we register our
own handler that prints a message similar to fatal errors, then aborts.
We also call the function that registers the C++ `std::new_handler`.
|
|
Adding support of quirky filesystems occuring in virtualised settings not
having full POSIX support for memory mapped files. Example: current virtiofs
with cache disabled, occuring in Incus/LXD or Kata Containers. Has been
hitting various virtualised filesystems since 2016, depending on their levels
of maturity at the time. The situation will perhaps improve when virtiofs DAX
support patches will have made it into the qemu mainline.
On a reliability level, using the MAP_PRIVATE sycall flag instead of the
MAP_SHARED syscall flag for the mmap() system call does have some undefined
behaviour when the caller update the memory mapping of the mmap()ed file, but
MAP_SHARED does allow not only the calling process but other processes to
modify the memory mapping. Thus, in the current context, using MAP_PRIVATE
copy-on-write is marginally more reliable than MAP_SHARED.
This discussion of reliability is orthogonal to the type system enforced safety
policy of rust, which does not claim to handle memory modification of memory
mapped files triggered through the operating system and not the running rust
process.
|
|
Rollup of 6 pull requests
Successful merges:
- #122254 (Detect calls to .clone() on T: !Clone types on borrowck errors)
- #122495 (Visually mark 👻hidden👻 items with document-hidden-items)
- #122543 (Add `#![rustc_never_type_mode = "..."]` crate-level attribute to allow experimenting)
- #122560 (Safe Transmute: Use 'not yet supported', not 'unspecified' in errors)
- #122562 (Mention labelled blocks in `break` docs)
- #122563 (CI: cache PR CI Docker builds)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Safe Transmute: Use 'not yet supported', not 'unspecified' in errors
We can (and will) support analyzing the transmutability of types whose layouts aren't completely specified by its repr. This change ensures that the error messages remain sensible after this support lands.
r? ``@compiler-errors``
|
|
Add `#![rustc_never_type_mode = "..."]` crate-level attribute to allow experimenting
Demonstrating how different approaches with the never type work is somewhat hard when you can't actually provide a runnable example. Let's add features that change the fallback behavior.
This adds `#![rustc_never_type_mode = "no_fallback"]` and `#![rustc_never_type_mode = "fallback_to_never"]`, but I also plan to add others (in future PRs).
cc ``@traviscross``
r? ``@compiler-errors``
|
|
Detect calls to .clone() on T: !Clone types on borrowck errors
When encountering a lifetime error on a type that *holds* a type that doesn't implement `Clone`, explore the item's body for potential calls to `.clone()` that are only cloning the reference `&T` instead of `T` because `T: !Clone`. If we find this, suggest `T: Clone`.
```
error[E0502]: cannot borrow `*list` as mutable because it is also borrowed as immutable
--> $DIR/clone-on-ref.rs:7:5
|
LL | for v in list.iter() {
| ---- immutable borrow occurs here
LL | cloned_items.push(v.clone())
| ------- this call doesn't do anything, the result is still `&T` because `T` doesn't implement `Clone`
LL | }
LL | list.push(T::default());
| ^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
LL |
LL | drop(cloned_items);
| ------------ immutable borrow later used here
|
help: consider further restricting this bound
|
LL | fn foo<T: Default + Clone>(list: &mut Vec<T>) {
| +++++++
```
```
error[E0505]: cannot move out of `x` because it is borrowed
--> $DIR/clone-on-ref.rs:23:10
|
LL | fn qux(x: A) {
| - binding `x` declared here
LL | let a = &x;
| -- borrow of `x` occurs here
LL | let b = a.clone();
| ------- this call doesn't do anything, the result is still `&A` because `A` doesn't implement `Clone`
LL | drop(x);
| ^ move out of `x` occurs here
LL |
LL | println!("{b:?}");
| ----- borrow later used here
|
help: consider annotating `A` with `#[derive(Clone)]`
|
LL + #[derive(Clone)]
LL | struct A;
|
```
Fix #48677.
|
|
Consolidate WF for aliases
Make RPITs/TAITs/weak (type) aliases/projections all enforce:
1. their nominal predicates
2. their args are WF
This possibly does extra work, but is also nice for consistency sake.
r? lcnr
|
|
|
|
|
|
|
|
We can (and will) support analyzing the transmutability of types
whose layouts aren't completely specified by its repr. This change
ensures that the error messages remain sensible after this support
lands.
|
|
Rollup of 6 pull requests
Successful merges:
- #114651 (rustdoc: add `--test-builder-wrapper` arg to support wrappers such as RUSTC_WRAPPER when building doctests)
- #122468 (Cleanup `MirBorrowckCtxt::prefixes`)
- #122496 (Greatly reduce GCC build logs)
- #122512 (Cursor.rs documentation fix)
- #122513 (hir: Remove `opt_local_def_id_to_hir_id` and `opt_hir_node_by_def_id`)
- #122530 (less symbol interner locks)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
less symbol interner locks
This reduces instructions under 1% (in rustdoc run), but essentially free.
|
|
hir: Remove `opt_local_def_id_to_hir_id` and `opt_hir_node_by_def_id`
Also replace a few `hir_node()` calls with `hir_node_by_def_id()`.
Follow up to https://github.com/rust-lang/rust/pull/120943.
|
|
Cleanup `MirBorrowckCtxt::prefixes`
Some of the uses of this method aren't necessary anymore and `PrefixSet::Supporting` is not used anywhere.
With `PrefixSet::Supporting` removed, this could technically be moved to an extension trait on `PlaceRef`. However, it would have to be moved back to `MirBorrowckCtxt` when the `Derefer` MIR pass is moved before borrowck so I didn't.
|
|
link.exe: Don't embed full path to PDB file in binary.
This PR makes `rustc` unconditionally pass `/PDBALTPATH:%_PDB%` to MSVC-style linkers, causing the linker to only embed the filename of the PDB in the binary instead of the full path. This will help implement the [trim-paths RFC](https://github.com/rust-lang/rust/issues/111540) for `*-msvc` targets.
Passing `/PDBALTPATH:%_PDB%` to the linker is already done by many projects that need reproducible builds and [debugger's should still be able to find the PDB](https://learn.microsoft.com/cpp/build/reference/pdbpath) if it is in the same directory as the binary.
r? `@ghost`
Fixes https://github.com/rust-lang/rust/issues/87825
|
|
Clean up AstConv
Split off from #120926 to make it only contain the renaming & (doc) comment updates.
Any changes other than that which have accumulated over time are now part of this PR.
Let's be disciplined ;) Inspired by https://github.com/rust-lang/rust/pull/120926#issuecomment-1997984483.
---
* Remove `hir_trait_to_predicates`
* Unused since #113671
* Inline `create_args_for_ast_trait_ref`
* Only had a single call site
* Having it as a separate method didn't gain us anything
* Use an if-let guard somewhere to avoid unwrapping
* Avoid explicit trait object lifetimes
* More legible, stylistic-only (the updated code is 100% semantically identical)
* Use explicitly elided lifetimes in impl headers, they get elaborated to distinct lifetimes
* Make use of [object lifetime defaulting](https://doc.rust-lang.org/reference/lifetime-elision.html#default-trait-object-lifetimes) for a trait object type inside of a reference type somewhere
* Use preexisting dedicated method `ItemCtxt::to_ty` over `<dyn AstConv<'_>>::ast_ty_to_ty`
* Use preexisting dedicated method `AstConv::astconv` over explicit coercions
* Simplify the function signature of `create_args_for_ast_path` and of `check_generic_arg_count`
* In both cases redundant information was passed rendering the call sites verbose and confusing
* No perf impact (tested in [#120926](https://github.com/rust-lang/rust/pull/120926))
* Move diagnostic method `report_ambiguous_associated_type` from `astconv` to `astconv::errors`
* The submodule `errors` exists specifically for that purpose
* Use it to keep the main module clean & short
|
|
Docs for `thir::ExprKind::Use` and `thir::ExprKind::Let`
These docs are based on my own recent investigations; hopefully they're reasonably accurate.
`Use` was particularly puzzling to me at first, since the name is not very suggestive, and the old docs were quite cryptic.
|
|
Ensure RPITITs are created before def-id freezing
From the test:
```rust
// `ty::Error` in a trait ref will silence any missing item errors, but will also
// prevent the `associated_items` query from being called before def ids are frozen.
```
Essentially, the code that checks that `impl`s have all their items (`check_impl_items_against_trait`) is also (implicitly) responsible for fetching the `associated_items` query before, but since we early return here:
https://github.com/rust-lang/rust/blob/c2901f543577af99b9cb708f5c0d28525eb7f08f/compiler/rustc_hir_analysis/src/check/check.rs#L732-L737
...that means that this never happens for trait refs that reference errors.
Fixes #122518
r? oli-obk
|
|
Pass the correct DefId when suggesting writing the aliased Self type out
Fixes #122467.
|
|
preserve span when evaluating mir::ConstOperand
This lets us show to the user where they were using the faulty const (which can be quite relevant when generics are involved).
I wonder if we should change "erroneous constant encountered" to something like "the above error was encountered while evaluating this constant" or so, to make this more similar to what the collector emits when showing a "backtrace" of where things get monomorphized? It seems a bit strange to rely on the order of emitted diagnostics for that but it seems the collector already [does that](https://github.com/rust-lang/rust/blob/da8a8c9223722e17cc0173ce9490076b4a6d263d/compiler/rustc_monomorphize/src/collector.rs#L472-L475).
|
|
diagnostics: suggest `Clone` bounds when noop `clone()`
Fixes #121524
|
|
Add `-Z external-clangrt`
This adds the unstable `-Z external-clangrt` flag that will prevent rustc from emitting linker paths for the in-tree LLVM sanitizer runtime library.
|
|
|
|
|
|
|
