| 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``
|
|
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
|
|
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
|
|
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``
|
|
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.
|
|
|
|
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`
|
|
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
|
|
|
|
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`
|
|
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.
|
|
replace build with check
Co-authored-by: Michael Goulet <michael@errs.io>
use appropriate test name
|
|
|
|
|
|
|
|
Remember names of `cfg`-ed out items to mention them in diagnostics
# Examples
## `serde::Deserialize` without the `derive` feature (a classic beginner mistake)
I had to slightly modify serde so that it uses explicit re-exports instead of a glob re-export. (Update: a serde PR was merged that adds the manual re-exports)
```
error[E0433]: failed to resolve: could not find `Serialize` in `serde`
--> src/main.rs:1:17
|
1 | #[derive(serde::Serialize)]
| ^^^^^^^^^ could not find `Serialize` in `serde`
|
note: crate `serde` has an item named `Serialize` but it is inactive because its cfg predicate evaluated to false
--> /home/gh-Nilstrieb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.160/src/lib.rs:343:1
|
343 | #[cfg(feature = "serde_derive")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
344 | pub use serde_derive::{Deserialize, Serialize};
| ^^^^^^^^^
= note: the item is gated behind the `serde_derive` feature
= note: see https://doc.rust-lang.org/cargo/reference/features.html for how to activate a crate's feature
```
(the suggestion is not ideal but that's serde's fault)
I already tested the metadata size impact locally by compiling the `windows` crate without any features. `800k` -> `809k`
r? `@ghost`
|
|
|
|
fix(expand): prevent infinity loop in macro containing only "///"
Fixes https://github.com/rust-lang/rust/issues/112342
Issue #112342 was caused by an infinity loop in `parse_tt_inner`, and the state of it is as follows:
- `matcher`: `[Sequence, Token(Doc), SequenceKleeneOpNoSep(op: ZeroOrMore), Eof]`
- loop:
| Iteration | Action |
| - | - |
| 0 | enter `Sequence`|
| 1 | enter `Token(Doc)` and `mp.idx += 1` had been executed |
| 2 | enter `SequenceKleeneOpNoSep` and reset `mp.idx` to `1` |
| 3 | enter `Token(Doc)` again|
To prevent the infinite loop, a check for whether it only contains `DocComment` in `check_lhs_no_empty_seq` had been added.
|
|
Add `-Ztrait-solver=next-coherence`
Flag that conditionally uses the trait solver *only* during coherence, for more testing and/or eventual partial-migration onto the trait solver (in the medium- to long-term).
* This still uses the selection context in some of the coherence methods I think, so it's not "complete". Putting this up for review and/or for further work in-tree.
* I probably need to spend a bit more time making sure that we don't sneakily create any other infcx's during coherence that also need the new solver enabled.
r? `@lcnr`
|
|
Fall back to bidirectional normalizes-to if no subst-relate candidate in alias-relate goal
Sometimes we get into the case where the choice of normalizes-to branch in alias-relate are both valid, but we cannot make a choice of which one to take because they are different -- either returning equivalent but permuted region constraints, or equivalent opaque type definitions but differing modulo normalization.
In this case, we can make progress by considering a fourth candidate where we compute both normalizes-to branches together and canonicalize that as a response. This is essentially the AND intersection of both normalizes-to branches. In an ideal world, we'd be returning something more like the OR intersection of both branches, but we have no way of representing that either for regions (maybe eventually) or opaques (don't see that happening ever).
This is incomplete, so like the subst-relate fallback it's only considered outside of coherence. But it doesn't seem like a dramatic strengthening of inference or anything, and is useful for helping opaque type inference succeed when the hidden type is a projection.
## Example
Consider the goal - `AliasRelate(Tait, <[i32; 32] as IntoIterator>::IntoIter)`.
We have three ways of currently solving this goal:
1. SubstRelate - fails because we can't directly equate the substs of different alias kinds.
2. NormalizesToRhs - `Tait normalizes-to <[i32; 32] as IntoIterator>::IntoIter`
* Ends up infering opaque definition - `Tait := <[i32; 32] as IntoIterator>::IntoIter`
3. NormalizesToLhs - `<[i32; 32] as IntoIterator>::IntoIter normalizes-to Tait`
* Find impl candidate, substitute the associated type - `std::array::IntoIter<i32, 32>`
* Equate `std::array::IntoIter<i32, 32>` and `Tait`
* Ends up infering opaque definition - `Tait := std::array::IntoIter<i32, 32>`
The problem here is that 2 and 3 are essentially both valid, since we have aliases that normalize on both sides, but due to lazy norm, they end up inferring different opaque type definitions that are only equal *after* normalizing them further.
---
r? `@lcnr`
|
|
Emit an error when return-type-notation is used with type/const params
These are not intended to be supported initially, even though the compiler supports them internally...
|
|
|
|
- remove useless commands from test Makefile
- do not unnecessarily remove metadata temporary files because they'll be managed by MaybeTempDir
- remove unused FailedRemove error introduced by this PR
|
|
If `-o -` or `--emit KIND=-` is provided, output will be written
to stdout instead. Binary output (`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.
|
|
Rollup of 8 pull requests
Successful merges:
- #111250 (Add Terminator conversion from MIR to SMIR, part #2)
- #112310 (Add new Tier-3 targets: `loongarch64-unknown-none*`)
- #112334 (Add myself to highfive rotation)
- #112340 (remove `TyCtxt::has_error_field` helper method)
- #112343 (Prevent emitting `missing_docs` for `pub extern crate`)
- #112350 (Avoid duplicate type sanitization of local decls in borrowck)
- #112356 (Fix comment for `get_region_var_origins`)
- #112358 (Remove default visitor impl in region constraint generation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Prevent emitting `missing_docs` for `pub extern crate`
Fixes #112308.
r? `@notriddle`
|
|
|
|
|
|
|
|
diagnostics: do not suggest type name tweaks on type-inferred closure args
Fixes #111932
|
|
Fix suggestion for matching struct with `..` on both ends
### Before This PR
```
error: expected `}`, found `,`
--> src\main.rs:8:17
|
8 | Foo { .., x, .. } => (),
| --^
| | |
| | expected `}`
| `..` must be at the end and cannot have a trailing comma
|
help: move the `..` to the end of the field list
|
8 - Foo { .., x, .. } => (),
8 + Foo { .., x, , .. } => (),
|
```
### After This PR
```
error: expected `}`, found `,`
--> tests/ui/parser/issue-112188.rs:11:17
|
11 | let Foo { .., x, .. } = f; //~ ERROR expected `}`, found `,`
| --^-
| | |
| | expected `}`
| `..` must be at the end and cannot have a trailing comma
| help: remove the starting `..`
```
Fixes #112188.
|
|
Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure
Current suggestion for when taking a mutable reference to `self` in a closure (as an upvar) will produce a machine-applicable suggestion to change the `self` in the function signature to `mut self`, but does not account for the specialness of implicit self in that it can already have `&` and `&mut` (see #111554). This causes the function signature to become `test(&mut mut self)` which does not seem desirable.
```
error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable
--> src/sound_player.rs:870:11
|
869 | pub fn test(&mut self) {
| ---- help: consider changing this to be mutable: `mut self`
870 | || test2(&mut self);
| ^^^^^^^^^ cannot borrow as mutable
```
This PR suppresses the "changing this to be mutable" suggestion if the implicit self is either `ImplicitSelfKind::ImmRef` or `ImplicitSelfKind::MutRef`.
Fixes #111554.
|
|
Correct fortanix LVI test print function
A recent change resulted in a different machine code for the `print` function. This caused the LVI test for this function to fail. This PR:
- Fixes the test for the `print` function
- Simplified the test a bit so future modifications are more unlikely
cc: ``@jethrogb``
|
|
|
