| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #112260 (Improve document of `unsafe_code` lint)
- #112429 ([rustdoc] List matching impls on type aliases)
- #112442 (Deduplicate identical region constraints in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiler-errors:next-solver-deduplicate-region-constraints, r=lcnr
Deduplicate identical region constraints in new solver
the new solver doesn't track whether we've already proven a goal like the fulfillment context's obligation forest does, so we may be instantiating a canonical response (and specifically, its nested region obligations) quite a few times.
This may lead to exponentially gathering up identical region constraints for things like auto traits, so let's deduplicate region constraints when in `compute_external_query_constraints`.
r? ``@lcnr``
|
|
[rustdoc] List matching impls on type aliases
Fixes #32077.
Thanks a lot to ``@lcnr`` who helped me a lot with this fix!
cc ``@notriddle``
r? ``@lcnr``
|
|
Improve document of `unsafe_code` lint
This PR add another `unsafe_code` lint example, want to close #111967
|
|
Uplift `clippy::undropped_manually_drops` lint
This PR aims at uplifting the `clippy::undropped_manually_drops` lint.
## `undropped_manually_drops`
(warn-by-default)
The `undropped_manually_drops` lint check for calls to `std::mem::drop` with a value of `std::mem::ManuallyDrop` which doesn't drop.
### Example
```rust
struct S;
drop(std::mem::ManuallyDrop::new(S));
```
### Explanation
`ManuallyDrop` does not drop it's inner value so calling `std::mem::drop` will not drop the inner value of the `ManuallyDrop` either.
-----
Mostly followed the instructions for uplifting an clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::undropped_manually_drops` into rustc
|
|
Signed-off-by: Eval EXEC <execvy@gmail.com>
|
|
Write to stdout if `-` is given as output file
With this PR, if `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (those of type `obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together.
This implements https://github.com/rust-lang/compiler-team/issues/431
The idea behind the changes is to introduce an `OutFileName` enum that represents the output - be it a real path or stdout - and to use this enum along the code paths that handle different output types.
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #112323 (Don't mention already-set fields in struct constructor missing field error)
- #112395 (Add Terminator::InlineAsm conversion from MIR to SMIR)
- #112411 (add programmerjake to portable-simd cc list)
- #112428 (Structurally resolve pointee in `check_pat_lit`)
- #112444 (Don't debug-print `Interned` or `PrivateZst`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't debug-print `Interned` or `PrivateZst`
Instead of, e.g.
`PredefinedOpaques(Interned(PredefinedOpaquesData { ... }, PrivateZst))`
print:
`PredefinedOpaques(PredefinedOpaquesData { ... })`
Mostly observable in debug logs, or ICE backtraces where I saw this.
r? ``@nnethercote``
|
|
Structurally resolve pointee in `check_pat_lit`
Gotta make sure to eager norm the pointee of the match scrutinee with the new solver.
r? ``@lcnr``
|
|
add programmerjake to portable-simd cc list
|
|
Add Terminator::InlineAsm conversion from MIR to SMIR
This is the last variant that needed to be covered for Terminator. As we've discussed with ``@oli-obk`` I've made a lot of it's fields be `String`s.
r? ``@oli-obk``
|
|
r=WaffleLapkin
Don't mention already-set fields in struct constructor missing field error
Fixes #111149
|
|
r=WaffleLapkin
Misc HIR typeck type mismatch tweaks
These are all intended to improve #112104, but I couldn't get it to actually suggest adding `as_ref` to the LHS of the equality expr without some hacks that I may play around with some more.
Each commit's title should explain what it's doing except for perhaps the last one, which addresses the bogus suggestion on #112104 itself.
|
|
|
|
Take MIR dataflow analyses by mutable reference
The main motivation here is any analysis requiring dynamically sized scratch memory to work. One concrete example would be pointer target tracking, where tracking the results of a dereference can result in multiple possible targets. This leads to processing multi-level dereferences requiring the ability to handle a changing number of potential targets per step. A (simplified) function for this would be `fn apply_deref(potential_targets: &mut Vec<Target>)` which would use the scratch space contained in the analysis to send arguments and receive the results.
The alternative to this would be to wrap everything in a `RefCell`, which is what `MaybeRequiresStorage` currently does. This comes with a small perf cost and loses the compiler's guarantee that we don't try to take multiple borrows at the same time.
For the implementation:
* `AnalysisResults` is an unfortunate requirement to avoid an unconstrained type parameter error.
* `CloneAnalysis` could just be `Clone` instead, but that would result in more work than is required to have multiple cursors over the same result set.
* `ResultsVisitor` now takes the results type on in each function as there's no other way to have access to the analysis without cloning it. This could use an associated type rather than a type parameter, but the current approach makes it easier to not care about the type when it's not necessary.
* `MaybeRequiresStorage` now no longer uses a `RefCell`, but the graphviz formatter now does. It could be removed, but that would require even more changes and doesn't really seem necessary.
|
|
|
|
Move tests from `ui/discrim` dir
It seems that we already have a `enum-discriminant` with more tests, so it makes sense to merge them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #109953 (Use 128 bits for TypeId hash)
- #112333 (Don't hold the active queries lock while calling `make_query`)
- #112339 (Fix rust-analyzer proc macro server)
- #112410 (Do `fix_*_builtin_expr` hacks on the writeback results)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Do `fix_*_builtin_expr` hacks on the writeback results
During writeback, we do `fix_{scalar,index}_builtin_expr` so that during MIR build we generate built-in MIR instructions instead of method calls for certain built-in arithmetic operations. We do this by checking the types of these built-in operations are scalar types, and remove the method def-id to essentially mark the operation as built-in and not "overloaded".
For lazy norm and the new trait solver, this is a problem, because we don't actually normalize all the types we end up seeing in the typeck results until they're copied over writeback's copy of the typeck results. To fix this, delay these fixup calls until after this normalization has been done.
This doesn't affect the old trait solver, but does simplify the code a bit IMO, since we can remove a few sets of calls to `resolve_vars_if_possible` and some `borrow_mut`s.
r? `@lcnr`
|
|
Fix rust-analyzer proc macro server
The feature now exists on `proc-macro-srv-cli`, and without it the proc macro server will bail rigth out.
CC https://github.com/rust-lang/rust-analyzer/issues/14991
|
|
Don't hold the active queries lock while calling `make_query`
This moves the call to `make_query` outside the parts that holds the active queries lock in `try_collect_active_jobs`. This should help removed the deadlock and borrow panic that has been observed when printing the query stack during an ICE.
cc `@SparrowLii`
r? `@cjgillot`
|
|
Use 128 bits for TypeId hash
Preliminary/Draft impl of https://github.com/rust-lang/compiler-team/issues/608
Prior art (probably incomplete list)
- https://github.com/rust-lang/rust/pull/75923
- https://github.com/rust-lang/rust/pull/95845
|
|
Rollup of 9 pull requests
Successful merges:
- #112034 (Migrate `item_opaque_ty` to Askama)
- #112179 (Avoid passing --cpu-features when empty)
- #112309 (bootstrap: remove dependency `is-terminal`)
- #112388 (Migrate GUI colors test to original CSS color format)
- #112389 (Add a test for #105709)
- #112392 (Fix ICE for while loop with assignment condition with LHS place expr)
- #112394 (Remove accidental comment)
- #112396 (Track more diagnostics in `rustc_expand`)
- #112401 (Don't `use compile_error as print`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Don't `use compile_error as print`
I've spent **1.5 hours** debugging this while trying to compile #112400, if we use `compile_error!`, we should not just forward user input to it, but issue a reasonable error message.
The better solution would be to use a lint like `clippy::print_stdout`, but since we don't have clippy in CI, let's at least make the macro error better.
Also note that some functions called here actually do use `println` (see for example `print_type_sizes` function).
|
|
Track more diagnostics in `rustc_expand`
I wish we could lint this somehow...
|
|
Remove accidental comment
Left this in in #110092 while debugging, thanks to `@WaffleLapkin` for spotting
|
|
Fix ICE for while loop with assignment condition with LHS place expr
Fixes #112385.
|
|
Add a test for #105709
Closes #105709
|
|
Migrate GUI colors test to original CSS color format
Follow-up of https://github.com/rust-lang/rust/pull/111459.
r? `@notriddle`
|
|
bootstrap: remove dependency `is-terminal`
|
|
Avoid passing --cpu-features when empty
Added in 12ac719b99560072cbe52a957f22d3fe6946cf2a, this logic always
passed --cpu-features, even when the value was the empty string.
|
|
Migrate `item_opaque_ty` to Askama
This PR migrates `item_opaque_ty` to Askama
Refers: https://github.com/rust-lang/rust/issues/108868
|
|
Removed use of iteration through a HashMap/HashSet in rustc_incremental and replaced with IndexMap/IndexSet
This allows for the `#[allow(rustc::potential_query_instability)]` in rustc_incremental to be removed, moving towards fixing #84447 (although a LOT more modules have to be changed to fully resolve it). Only HashMaps/HashSets that are being iterated through have been modified (although many structs and traits outside of rustc_incremental had to be modified as well, as they had fields/methods that involved a HashMap/HashSet that would be iterated through)
I'm making a PR for just 1 module changed to test for performance regressions and such, for future changes I'll either edit this PR to reflect additional modules being converted, or batch multiple modules of changes together and make a PR for each group of modules.
|
