Make `Clean` take &mut DocContext
- Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics`
- Take `&mut DocContext` in most of `clean`
- Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad.
This combined with https://github.com/rust-lang/rust/pull/82018 should hopefully help with https://github.com/rust-lang/rust/pull/82014 by allowing `cx.cache.exported_traits` to be modified in `register_res`. Previously it had to use interior mutability, which required either adding a RefCell to `cache.exported_traits` on *top* of the existing `RefCell<Cache>` or mixing reads and writes between `cx.exported_traits` and `cx.cache.exported_traits`. I don't currently have that working but I expect it to be reasonably easy to add after this.
rustdoc: Support argument files
Factors out the `rustc_driver` logic that handles argument files so that rustdoc supports them as well, e.g.:
rustdoc `@argfile`
This is needed to be able to generate docs for projects that already use argument files when compiling them, e.g. projects that pass a huge number of `--cfg` arguments.
The feature was stabilized for `rustc` in #66172.
Do not ICE when evaluating locals' types of invalid `yield`
When a `yield` is outside of a generator, check its value regardless to
avoid an ICE while trying to get all locals' types in writeback.
Fix#78653.
ast: Keep expansion status for out-of-line module items
I.e. whether a module `mod foo;` is already loaded from a file or not.
This is a pre-requisite to correctly treating inner attributes on such modules (https://github.com/rust-lang/rust/issues/81661).
With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`.
Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level.
Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`).
`ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.
name async generators something more human friendly in type error diagnostic
fixes#81457
Some details:
1. I opted to load the generator kind from the hir in TyCategory. I also use 1 impl in the hir for the descr
2. I named both the source of the future, in addition to the general type (`future`), not sure what is preferred
3. I am not sure what is required to make sure "generator" is not referred to anywhere. A brief `rg "\"generator\"" showed me that most diagnostics correctly distinguish from generators and async generator, but the `descr` of `DefKind` is pretty general (not sure how thats used)
4. should the descr impl of AsyncGeneratorKind use its display impl instead of copying the string?
Factors out the `rustc_driver` logic that handles argument files
so that rustdoc supports them as well, e.g.:
rustdoc @argfile
This is needed to be able to generate docs for projects that
already use argument files when compiling them, e.g. projects
that pass a huge number of `--cfg` arguments.
The feature was stabilized for `rustc` in #66172.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Changes from 81473 extended the dead code lint with an ability to detect
fields that are written to but never read from. The implementation skips
over fields on the left hand side of an assignment, without marking them
as live.
A field access might involve an automatic dereference and de-facto read
the field. Conservatively mark expressions with deref adjustments as
live to avoid generating false positive warnings.
Print -Ztime-passes (and misc stats/logs) on stderr, not stdout.
I've tried not to change anything that looked similar to `rustc --print`, where people might use automation, and/or any "bulk" prints, such as dumping an entire Graphviz (`dot`) graph on stdout.
The reason I want `-Ztime-passes` to be on stderr like debug logging is I can get a complete (and correctly interleaved) view just by looking at stderr, which is merely a convenience when running `rustc`/Cargo directly, but even more important when it's nested in a build script, as Cargo will split the build script output into stdout (named `output`) and `stderr`.
Optimize counting digits in line numbers during error reporting
Replaces `.to_string().len()` with simple loop and integer division, which avoids an unnecessary allocation.
Although I couldn't figure out how to directly profile `rustc`'s error reporting, I ran a microbenchmark on my machine (2.9 GHz Dual-Core Intel Core i5) on the two strategies for `0..100_000`, and the results seem promising:
```
test to_string_len ... bench: 12,124,792 ns/iter (+/- 700,652)
test while_loop ... bench: 30,333 ns/iter (+/- 562)
```
The x86_64 disassembly reduces integer division to a multiplication + shift, so I don't think there's any problems with using integer division.
For more (micro)optimization, it would be nice if we could avoid the initial check to see if the line number is nonzero, but I don't think `self.get_max_line_num(span, children)` _guarantees_ a nonzero line number.
Replace if-let and while-let with `if let` and `while let`
This pull request replaces if-let and while-let with `if let` and `while let`.
closes https://github.com/rust-lang/rust/issues/82205
const_generics: Dont evaluate array length const when handling yet another error
Same ICE as #82009 except triggered by a different error.
cc ``@lcnr``
r? ``@varkor``
Ensure valid TraitRefs are created for GATs
This fixes `ProjectionTy::trait_ref` to use the correct substs. Places that need all of the substs have been updated to not use `trait_ref`.
r? ````@jackh726````
It's not possible to check if removing a semicolon fixes the type error
when checking match arms and one or both of the last arm's and the
current arm's return types are imported "opaque" types. In these cases
we don't generate a "consider removing semicolon" suggestions.
Fixes#81839
Precompute ancestors when checking privacy
Precompute ancestors of the old error node set so that check for private
types and traits in public interfaces can in constant time determine if
the current item has any descendants in the old error set.
This removes disparity in compilation time between public and private type
aliases reported in #50614 (from 30 s to 5 s, in an example making extensive use
of private type aliases).
No functional changes intended.
Crate root is sufficiently different from `mod` items, at least at syntactic level.
Also remove customization point for "`mod` item or crate root" from AST visitors.
remove useless ?s (clippy::needless_question_marks)
Example code:
```rust
fn opts() -> Option<String> {
let s: Option<String> = Some(String::new());
Some(s?) // this can just be "s"
}
```
Use !Sync std::lazy::OnceCell in usefulness checking
The `rustc_data_structures::sync::OnceCell` is thread-safe when building
a parallel compiler. This is unnecessary for the purposes of pattern
usefulness checking. Use `!Sync` `std::lazy::OnceCell` instead.
Add diagnostics for specific cases for const/type mismatch err
For now, this adds at least more information so better diagnostics can be emitted for const mismatch errors.
I'm not sure what exactly we want to emit, so I've left notes there temporarily, also to see if this is the right approach
r? ```@lcnr```
cc: ```@estebank```
Implement RFC 2580: Pointer metadata & VTable
RFC: https://github.com/rust-lang/rfcs/pull/2580
~~Before merging this PR:~~
* [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278).
* [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513
* [x] Update `#[unstable]` attributes in the PR with the tracking issue number
----
This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts, parameters can be assumed to implement it without a corresponding bound.
For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals, so careful review is appreciated.
This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`:
```rust
pub trait Pointee {
/// One of `()`, `usize`, or `DynMetadata<dyn SomeTrait>`
type Metadata: Copy + Send + Sync + Ord + Hash + Unpin;
}
pub trait Thin = Pointee<Metadata = ()>;
pub const fn metadata<T: ?Sized>(ptr: *const T) -> <T as Pointee>::Metadata {}
pub const fn from_raw_parts<T: ?Sized>(*const (), <T as Pointee>::Metadata) -> *const T {}
pub const fn from_raw_parts_mut<T: ?Sized>(*mut (),<T as Pointee>::Metadata) -> *mut T {}
impl<T: ?Sized> NonNull<T> {
pub const fn from_raw_parts(NonNull<()>, <T as Pointee>::Metadata) -> NonNull<T> {}
/// Convenience for `(ptr.cast(), metadata(ptr))`
pub const fn to_raw_parts(self) -> (NonNull<()>, <T as Pointee>::Metadata) {}
}
impl<T: ?Sized> *const T {
pub const fn to_raw_parts(self) -> (*const (), <T as Pointee>::Metadata) {}
}
impl<T: ?Sized> *mut T {
pub const fn to_raw_parts(self) -> (*mut (), <T as Pointee>::Metadata) {}
}
/// `<dyn SomeTrait as Pointee>::Metadata == DynMetadata<dyn SomeTrait>`
pub struct DynMetadata<Dyn: ?Sized> {
// Private pointer to vtable
}
impl<Dyn: ?Sized> DynMetadata<Dyn> {
pub fn size_of(self) -> usize {}
pub fn align_of(self) -> usize {}
pub fn layout(self) -> crate::alloc::Layout {}
}
unsafe impl<Dyn: ?Sized> Send for DynMetadata<Dyn> {}
unsafe impl<Dyn: ?Sized> Sync for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Debug for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Unpin for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Copy for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Clone for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Eq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialEq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Ord for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Hash for DynMetadata<Dyn> {}
```
API differences from the RFC, in areas noted as unresolved questions in the RFC:
* Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T`, following the precedent of `null`, `slice_from_raw_parts`, etc.
* Added `to_raw_parts`
An attempt to compute HIR stats for crates with nested foreign items results in an ICE.
```
fn main() {
extern "C" { fn f(); }
}
```
```
thread 'rustc' panicked at 'visit_nested_xxx must be manually implemented in this visitor'
```
Provide required implementation of visitor method.
When building rustc with `-Codegen-units=1` this inline hint ensures
that obtaining already initialized head constructor does not involve
a function call overhead and reduces the instruction count in
match-stress-enum-check full benchmark from 11.9G to 9.8G.
It shouldn't have significant impact on the currently default
configuration where it reflects existing inlining decisions.
Implement reborrow for closure captures
The strategy for captures is detailed here with examples: https://hackmd.io/PzxYMPY4RF-B9iH9uj9GTA
Key points:
- We only need to reborrow a capture in case of move closures.
- If we mutate something via a `&mut` we store it as a `MutBorrow`/`UniqueMuBorrow` of the path containing the `&mut`,
- Similarly, if it's read via `&` ref we just store it as a `ImmBorrow` of the path containing the `&` ref.
- If a path doesn't deref a `&mut`, `&`, then that path is captured by Move.
- If the use of a path results in a move when the closure is called, then that path is truncated before any deref and the truncated path is moved into the closure.
- In the case of non-move closure if a use of a path results in a move, then the path is truncated before any deref and the truncated path is moved into the closure.
Note that the implementation differs a bit from the document to allow for truncated path to be used in the ClosureKind analysis that happens as part of the first capture analysis pass.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/31
r? ````@nikomatsakis````
Placeholder lifetime error cleanup
- Remove note of trait definition
- Avoid repeating the same self type
- Use original region names when possible
- Use this error kind more often
- Print closure signatures when they are suppose to implement `Fn*` traits
Works towards #57374
r? ```@nikomatsakis```
Fix debug information for function arguments of type &str or slice.
Issue details:
When lowering MIR to LLVM IR, the compiler decomposes every &str and slice argument into a data pointer and a usize. Then, the original argument is reconstructed from the pointer and the usize arguments in the body of the function that owns it. Since the original argument is declared in the body of a function, it should be marked as a LocalVariable instead of an ArgumentVairable. This confusion causes MSVC debuggers unable to visualize &str and slice arguments correctly. (See https://github.com/rust-lang/rust/issues/81894 for more details).
Fix details:
Making sure that the debug variable for every &str and slice argument is marked as LocalVariable instead of ArgumentVariable in computing_per_local_var_debug_info. This change has been verified on VS Code debugger, VS debugger, WinDbg and LLDB.
Fix SourceMap::start_point
`start_point` needs to return the *first* character's span, but it would
previously call `find_width_of_character_at_span` which returns the span
of the *last* character. The implementation is now fixed.
Other changes:
- Docs for start_point, end_point, find_width_of_character_at_span
updated
- Minor simplification in find_width_of_character_at_span code
Fixes#81800
Don't fail to remove files if they are missing
In the backend we may want to remove certain temporary files, but in
certain other situations these files might not be produced in the first
place. We don't exactly care about that, and the intent is really that
these files are gone after a certain point in the backend.
Here we unify the backend file removing calls to use `ensure_removed`
which will attempt to delete a file, but will not fail if it does not
exist (anymore).
The tradeoff to this approach is, of course, that we may miss instances
were we are attempting to remove files at wrong paths due to some bug –
compilation would silently succeed but the temporary files would remain
there somewhere.
Add 'consider using' message to overflowing_literals
Fixes#79744.
Ironically, the `overflowing_literals` handler for binary or hex already
had this message! You would think it would be the other way around :)
cc ```@scottmcm```
- Take `FnMut` in `rustc_trait_selection::find_auto_trait_generics`
- Take `&mut DocContext` in most of `clean`
- Collect the iterator in auto_trait_impls instead of iterating lazily; the lifetimes were really bad.
- Changes `fn sess` to properly return a borrow with the lifetime of `'tcx`, not the mutable borrow.
Only store a LocalDefId in some HIR nodes
Some HIR nodes are guaranteed to be HIR owners: Item, TraitItem, ImplItem, ForeignItem and MacroDef.
As a consequence, we do not need to store the `HirId`'s `local_id`, and we can directly store a `LocalDefId`.
This allows to avoid a bit of the dance with `tcx.hir().local_def_id` and `tcx.hir().local_def_id_to_hir_id` mappings.
validation: fix invalid-fn-ptr error message
https://github.com/rust-lang/rust/pull/82061 changed the code here to print an `ImmTy` instead of a `ScalarMaybeUninit`; that was an accident. So go back to printing a `ScalarMaybeUninit`.
r? ```@oli-obk```
avoid full-slicing slices
If we already have a slice, there is no need to get another full-range slice from that, just use the original.
clippy::redundant_slicing
This change tunes ahead-of-time codegening according to the amount of
concurrency available, rather than according to the number of CPUs on
the system. This can lower memory usage by reducing the number of
compiled LLVM modules in memory at once, particularly across several
rustc instances.
Previously, each rustc instance would assume that it should codegen
ahead of time to meet the demand of number-of-CPUs workers. But often, a
rustc instance doesn't have nearly that much concurrency available to
it, because the concurrency availability is split, via the jobserver,
across all active rustc instances spawned by the driving cargo process,
and is further limited by the `-j` flag argument. Therefore, each rustc
might have had several times the number of LLVM modules in memory than
it really needed to meet demand. If the modules were large, the effect
on memory usage would be noticeable.
With this change, the required amount of ahead-of-time codegen scales up
with the actual number of workers running within a rustc instance. Note
that the number of workers running can be less than the actual
concurrency available to a rustc instance. However, if more concurrency
is actually available, workers are spun up quickly as job tokens are
acquired, and the ahead-of-time codegen scales up quickly as well.
Along the way, we also implement a handful of diagnostics improvements
and fixes, particularly with respect to the special handling of `||` in
place of `|` and when there are leading verts in function params, which
don't allow top-level or-patterns anyway.
32-bit ARM: Emit `lr` instead of `r14` when specified as an `asm!` output register.
On 32-bit ARM platforms, the register `r14` has the alias `lr`. When used as an output register in `asm!`, rustc canonicalizes the name to `r14`. LLVM only knows the register by the name `lr`, and rejects it. This changes rustc's LLVM code generation to output `lr` instead.
closes#82052
r? ``@nagisa``
const_generics: Fix incorrect ty::ParamEnv::empty() usage
Fixes#80561
Not sure if I should keep the `debug!(..)`s or not but its the second time I've needed them so they sure seem useful lol
cc ``@lcnr``
r? ``@oli-obk``
const_generics: Dont evaluate array length const when handling errors
Fixes#79518Fixes#78246
cc ````@lcnr````
This was ICE'ing because we dont pass in the correct ``ParamEnv`` which meant that there was no ``Self: Foo`` predicate to make ``Self::Assoc`` well formed which caused an ICE when trying to normalize ``Self::Assoc`` in the mir interpreter
r? ````@varkor````
Suggest to create a new `const` item if the `fn` in the array is a `const fn`
Fixes#73734. If the `fn` in the array repeat expression is a `const fn`, suggest creating a new `const` item. On nightly, suggest creating an inline `const` block. This PR also removes the `suggest_const_in_array_repeat_expressions` as it is no longer necessary.
Example:
```rust
fn main() {
// Should not compile but hint to create a new const item (stable) or an inline const block (nightly)
let strings: [String; 5] = [String::new(); 5];
println!("{:?}", strings);
}
```
Gives this error:
```
error[E0277]: the trait bound `std::string::String: std::marker::Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:3:32
|
2 | let strings: [String; 5] = [String::new(); 5];
| ^^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `String`
|
= note: the `Copy` trait is required because the repeated element will be copied
```
With this change, this is the error message:
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:3:32
|
LL | let strings: [String; 5] = [String::new(); 5];
| ^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String`
|
= help: moving the function call to a new `const` item will resolve the error
```
Check the result cache before the DepGraph when ensuring queries
Split out of https://github.com/rust-lang/rust/pull/70951
Calling `ensure` on already forced queries is a common operation.
Looking at the results cache first is faster than checking the DepGraph for a green node.
On 32-bit ARM platforms, the register `r14` has the alias `lr`. When used as an output register in `asm!`, rustc canonicalizes the name to `r14`. LLVM only knows the register by the name `lr`, and rejects it. This changes rustc's LLVM code generation to output `lr` instead.
Add diagnostic items to the following types:
OsString (os_string_type)
PathBuf (path_buf_type)
Owned (to_owned_trait)
As well as the to_vec method on slice/[T]
The `rustc_data_structures::sync::OnceCell` is thread-safe when building
a parallel compiler. This is unnecessary for the purposes of pattern
usefulness checking. Use `!Sync` `std::lazy::OnceCell` instead.
Rollup of 11 pull requests
Successful merges:
- #80523 (#[doc(inline)] sym_generated)
- #80920 (Visit more targets when validating attributes)
- #81720 (Updated smallvec version due to RUSTSEC-2021-0003)
- #81891 ([rustdoc-json] Make `header` a vec of modifiers, and FunctionPointer consistent)
- #81912 (Implement the precise analysis pass for lint `disjoint_capture_drop_reorder`)
- #81914 (Fixing bad suggestion for `_` in `const` type when a function #81885)
- #81919 (BTreeMap: fix internal comments)
- #81927 (Add a regression test for #32498)
- #81965 (Fix MIR pretty printer for non-local DefIds)
- #82029 (Use debug log level for developer oriented logs)
- #82056 (fix ice (#82032))
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
In the backend we may want to remove certain temporary files, but in
certain other situations these files might not be produced in the first
place. We don't exactly care about that, and the intent is really that
these files are gone after a certain point in the backend.
Here we unify the backend file removing calls to use `ensure_removed`
which will attempt to delete a file, but will not fail if it does not
exist (anymore).
The tradeoff to this approach is, of course, that we may miss instances
were we are attempting to remove files at wrong paths due to some bug –
compilation would silently succeed but the temporary files would remain
there somewhere.
Use debug log level for developer oriented logs
The information logged here is of limited general interest, while at the
same times makes it impractical to simply enable logging and share the
resulting logs due to the amount of the output produced.
Reduce log level from info to debug for developer oriented information.
For example, when building cargo, this reduces the amount of logs
generated by `RUSTC_LOG=info cargo build` from 265 MB to 79 MB.
Continuation of changes from 81350.
Fix MIR pretty printer for non-local DefIds
Tries to fix#81200 -- the reproducer in the issue is not fixed yet.
Submitting PR to get feedback.
r? oli-obk
Fixing bad suggestion for `_` in `const` type when a function #81885Closes#81885
```
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> $DIR/typeck_type_placeholder_item_help.rs:13:22
|
LL | const TEST4: fn() -> _ = 42;
| ^
| |
| not allowed in type signatures
| help: use type parameters instead: `T`
```
Do not show the suggestion `help: use type parameters instead: T` when `fn`
Implement the precise analysis pass for lint `disjoint_capture_drop_reorder`
The precision pass for the lint prevents the lint from triggering for a variable (that was previously entirely captured by the closure) if all paths that need Drop starting at root variable have been captured by the closure.
r? `@nikomatsakis`
Updated smallvec version due to RUSTSEC-2021-0003
Hi.
Updated Cargo.toml's for smallvec due to RUSTSEC-2021-0003 and Cargo.toml in separate commit.
Affected function `SmallVec::insert_many` looks like don't was used directly in rust, but can be somewhere in deps.
There should be some mechanism to not to do this kind of things manually, like dependabot. Actually, dependabot supports rust and can check security articles (at least that noted in description).
Visit more targets when validating attributes
This begins to address #80048, allowing for additional validation of attributes.
There are more refactorings that can be done, though I think they should be tackled in additional PRs:
* ICE when a builtin attribute is encountered that is not checked
* Move some of the attr checking done `ast_validation` into `rustc_passes`
* note that this requires a bit of additional refactoring, especially of extern items which currently parse attributes (and thus are a part of the AST) but do not possess attributes in their HIR representation.
* Rename `Target` to `AttributeTarget`
* Refactor attribute validation completely to go through `Visitor::visit_attribute`.
* This would require at a minimum passing `Target` into this method which might be too big of a refactoring to be worth it.
* It's also likely not possible to do all the validation this way as some validation requires knowing what other attributes a target has.
r? `@davidtwco`
#[doc(inline)] sym_generated
Manually doc-inlines `rustc_span::sym_generated` into `sym`.
Previously the docs would not get inlined, causing the symbols to be undocumented as `sym_generated` is private.
r? `@jyn514`
As part of the effort to implement split dwarf debug info, we ended up
setting the compile unit location to the output directory rather than
the source directory. Furthermore, it seems like we failed to remap the
prefixes for this as well!
The desired behaviour is to instead set the `DW_AT_GNU_dwo_name` to a
path relative to compiler's working directory. This still allows
debuggers to find the split dwarf files, while not changing the
behaviour of the code that is compiling with regular debug info, and not
changing the compiler's behaviour with regards to reproducibility.
Fixes#82074
Change suggestion logic to filter and checking _before_ creating
specific resolution suggestion.
Assert earlier that suggestions contain code substitions to make it
easier in the future to debug invalid uses. If we find this becomes too
noisy in the wild, we can always make the emitter resilient to these
cases and remove the assertions.
Fix#78651.
This is a pure refactoring split out from #80689.
It represents the most invasive part of that PR, requiring changes in
every caller of `parse_outer_attributes`
In order to eagerly expand `#[cfg]` attributes while preserving the
original `TokenStream`, we need to know the range of tokens that
corresponds to every attribute target. This is accomplished by making
`parse_outer_attributes` return an opaque `AttrWrapper` struct. An
`AttrWrapper` must be converted to a plain `AttrVec` by passing it to
`collect_tokens_trailing_token`. This makes it difficult to accidentally
construct an AST node with attributes without calling `collect_tokens_trailing_token`,
since AST nodes store an `AttrVec`, not an `AttrWrapper`.
As a result, we now call `collect_tokens_trailing_token` for attribute
targets which only support inert attributes, such as generic arguments
and struct fields. Currently, the constructed `LazyTokenStream` is
simply discarded. Future PRs will record the token range corresponding
to the attribute target, allowing those tokens to be removed from an
enclosing `collect_tokens_trailing_token` call if necessary.
Drop an unnecessary intermediate variable
Neither does it shorten the code nor does it provide a helpful name.
`@rustbot` modify labels +C-cleanup +T-compiler
r? `@varkor`
Fix suggestion to introduce explicit lifetime
Addresses #81650
Error message after fix:
```
error[E0311]: the parameter type `T` may not live long enough
--> src/main.rs:25:11
|
24 | fn play_with<T: Animal + Send>(scope: &Scope, animal: T) {
| -- help: consider adding an explicit lifetime bound...: `T: 'a +`
25 | scope.spawn(move |_| {
| ^^^^^
|
note: the parameter type `T` must be valid for the anonymous lifetime #2 defined on the function body at 24:1...
--> src/main.rs:24:1
|
24 | fn play_with<T: Animal + Send>(scope: &Scope, animal: T) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...so that the type `[closure@src/main.rs:25:17: 27:6]` will meet its required lifetime bounds
--> src/main.rs:25:11
|
25 | scope.spawn(move |_| {
| ^^^^^
```
The information logged here is of limited general interest, while at the
same times makes it impractical to simply enable logging and share the
resulting logs due to the amount of the output produced.
Reduce log level from info to debug for developer oriented information.
For example, when building cargo, this reduces the amount of logs
generated by `RUSTC_LOG=info cargo build` from 265 MB to 79 MB.
Continuation of changes from 81350.
GAT/const_generics: Allow with_opt_const_param to return GAT param def_id
Fixes#75415Fixes#79666
cc ```@lcnr```
I've absolutely no idea who to r? for this...
Allow casting mut array ref to mut ptr
Allow casting mut array ref to mut ptr
We now allow two new casts:
- mut array reference to mut ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *mut usize;
We allow casting const array references to const pointers so not
allowing mut references to mut pointers was inconsistent.
- mut array reference to const ptr. Example:
let mut x: [usize; 2] = [0, 0];
let p = &mut x as *const usize;
This was similarly inconsistent as we allow casting mut references to
const pointers.
Existing test 'vector-cast-weirdness' updated to test both cases.
Fixes#24151
Try fast_reject::simplify_type in coherence before doing full check
This is a reattempt at landing #69010 (by `@jonas-schievink).` The change adds a fast path for coherence checking to see if there's no way for types to unify since full coherence checking can be somewhat expensive.
This has big effects on code generated by the [`windows`](https://github.com/microsoft/windows-rs) which in some cases spends as much as 20% of compilation time in the `specialization_graph_of` query. In local benchmarks this took a compilation that previously took ~500 seconds down to ~380 seconds.
This is surely not going to make a difference on much smaller crates, so the question is whether it will have a negative impact. #69010 was closed because some of the perf suite crates did show small regressions.
Additional discussion of this issue is happening [here](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/windows-rs.20perf).
