| Age | Commit message (Collapse) | Author | Lines |
|---|
|
When normalizing a projection which results in a cycle, we would
cache the result of `project_type` without the nested obligations
(because they're not needed for inference). This would result in
the nested obligations only being handled once in fulfill, which
would avoid the cycle error.
Fixes #79714, a regresion from #79305 caused by the removal of
`get_paranoid_cache_value_obligation`.
|
|
This avoid the hang/oom from #79714
|
|
Thanks to Vadim Petrochenkov who [told me what the fix was][z]!
[z]: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/finding.20which.20macro.20rule.20to.20use/near/220240422
|
|
This change breaks some code and doesn't appear to enable any new code.
|
|
|
|
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
|
|
This reverts commit 5ba961018c482e050af908de60e4f8bd1a00f0ae.
|
|
|
|
This reverts commit afa2a675453091773eb9dd1b19389725526224b9.
|
|
This reverts commit 0ad3da06843089c0bf10d6caa3fbbc72fa67787a.
|
|
resolve: Collapse `macro_rules` scope chains on the fly
Otherwise they grow too long and you have to endlessly walk through them when resolving macros or imports.
Addresses https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives/near/215750815
|
|
Add asm register information for SPIR-V
As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture), we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However, we cannot do so purely without frontend support: [this match](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_target/src/asm/mod.rs#L185) fails and so `asm!` is not supported ([error reported here](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_ast_lowering/src/expr.rs#L1095)). To resolve this, we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm), at which point the rust-gpu backend can do all the parsing and codegen that is needed.
This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. ``@Amanieu`` said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along.
I based this off the [wasm asm PR](https://github.com/rust-lang/rust/pull/78684), which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :(
---
Some open questions:
- What do we call the register class? Some context, SPIR-V is an SSA-based IR, there are "instructions" that create IDs (referred to as `<id>` in the spec), which can be referenced by other instructions. So, `reg` isn't exactly accurate, they're SSA IDs, not re-assignable registers.
- What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!`, but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents the `spirv` target from even reaching that codepath.
|
|
Implement destructuring assignment for structs and slices
This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.
Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.
This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).
Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.
Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.
r? ``@petrochenkov``
|
|
Fix rustdoc rendering of by-value mutable arguments in async fn
r? `@jyn514`
Fixes #76517.
|
|
|
|
Reusing bindings causes errors later in lowering:
```
error[E0596]: cannot borrow `vec` as mutable, as it is not declared as mutable
--> /checkout/src/test/ui/async-await/argument-patterns.rs:12:20
|
LL | async fn b(n: u32, ref mut vec: A) {
| ^^^^^^^^^^^
| |
| cannot borrow as mutable
| help: consider changing this to be mutable: `mut vec`
```
|
|
This should fix `rustdoc` rendering of by-value mutable arguments in
`async fn` contexts.
|
|
incr-comp: hash and serialize span end line/column
Hash both the length and the end location (line/column) of a span. If we
hash only the length, for example, then two otherwise equal spans with
different end locations will have the same hash. This can cause a
problem during incremental compilation wherein a previous result for a
query that depends on the end location of a span will be incorrectly
reused when the end location of the span it depends on has changed. A
similar analysis applies if some query depends specifically on the
length of the span, but we only hash the end location. So hash both.
Fix #46744, fix #59954, fix #63161, fix #73640, fix #73967, fix #74890, fix #75900
---
See #74890 for a more in-depth analysis.
I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.
|
|
Don't print thread ids and names in `tracing` logs
Before:
```
2:rustc INFO rustc_interface::passes Pre-codegen
2:rustcTy interner total ty lt ct all
2:rustc Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0%
2:rustc Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
2:rustc Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
2:rustc RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0%
2:rustc Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0%
2:rustc FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0%
2:rustc Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0%
2:rustc Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0%
2:rustc Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc total 1326 0.2% 0.1% 0.0% 0.0%
2:rustcInternalSubsts interner: #437
2:rustcRegion interner: #355
2:rustcStability interner: #1
2:rustcConst Stability interner: #0
2:rustcAllocation interner: #0
2:rustcLayout interner: #0
```
After:
```
INFO rustc_interface::passes Post-codegen
Ty interner total ty lt ct all
Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0%
Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0%
Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0%
FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0%
Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0%
Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0%
Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0%
Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0%
Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
total 1326 0.2% 0.1% 0.0% 0.0%
InternalSubsts interner: #437
Region interner: #355
Stability interner: #1
Const Stability interner: #0
Allocation interner: #0
Layout interner: #0
```
Closes https://github.com/rust-lang/rust/issues/78931
r? ``@oli-obk``
|
|
Do not collect tokens for doc comments
Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).
(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)
r? `@Aaron1011`
|
|
rustc_taret: Remove `TargetOptions::is_like_android`
This option was replaced by more specific options and is no longer used by the compiler.
|
|
rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`
Follow up to https://github.com/rust-lang/rust/pull/77729.
Changes the target spec hierarchy for Linux from
```
linux_base
├── linux_musl_base
└── linux_uclibc_base
```
where `linux_base` is really `linux_gnu_base` and the inheriting targets replace target env "gnu" with "musl"/"uclibc" to
```
linux_base
├── linux_gnu_base
├── linux_musl_base
└── linux_uclibc_base
```
which is slightly less confusing (I think).
|
|
Support inlining diverging function calls
The existing heuristic does penalize diverging calls to some degree, but since
it never inlined them previously it might need some further modifications.
Additionally introduce storage markers for all temporaries created by
the inliner. The temporary introduced for destination rebrorrow, didn't
use them previously.
|
|
Add flags customizing behaviour of MIR inlining
* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
functions with inline hint.
Having those as configurable flags makes it possible to experiment with with
different inlining thresholds and substantially increase test coverage of MIR
inlining when used with increased thresholds (for example, necessary to test
#78844).
|
|
look at assoc ct, check the type of nodes
an example where types matter are function objects, see the added test which previously passed.
Now does a shallow comparison of unevaluated constants.
r? ```@oli-obk```
|
|
|
|
This matches the capitalization of RiscV
|
|
|
|
Co-authored-by: varkor <github@varkor.com>
|
|
|
|
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.
A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.
The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
|
|
Before:
```
2:rustc INFO rustc_interface::passes Pre-codegen
2:rustcTy interner total ty lt ct all
2:rustc Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0%
2:rustc Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
2:rustc Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
2:rustc RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0%
2:rustc Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0%
2:rustc FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0%
2:rustc Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0%
2:rustc Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0%
2:rustc Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
2:rustc total 1326 0.2% 0.1% 0.0% 0.0%
2:rustcInternalSubsts interner: #437
2:rustcRegion interner: #355
2:rustcStability interner: #1
2:rustcConst Stability interner: #0
2:rustcAllocation interner: #0
2:rustcLayout interner: #0
```
After:
```
INFO rustc_interface::passes Post-codegen
Ty interner total ty lt ct all
Adt : 1078 81.3%, 0.0% 0.0% 0.0% 0.0%
Array : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
Slice : 1 0.1%, 0.0% 0.0% 0.0% 0.0%
RawPtr : 2 0.2%, 0.0% 0.0% 0.0% 0.0%
Ref : 4 0.3%, 0.1% 0.1% 0.0% 0.0%
FnDef : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
FnPtr : 76 5.7%, 0.0% 0.0% 0.0% 0.0%
Placeholder : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Generator : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
GeneratorWitness : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Dynamic : 3 0.2%, 0.0% 0.0% 0.0% 0.0%
Closure : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Tuple : 13 1.0%, 0.0% 0.0% 0.0% 0.0%
Bound : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Param : 146 11.0%, 0.0% 0.0% 0.0% 0.0%
Infer : 2 0.2%, 0.1% 0.0% 0.0% 0.0%
Projection : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Opaque : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
Foreign : 0 0.0%, 0.0% 0.0% 0.0% 0.0%
total 1326 0.2% 0.1% 0.0% 0.0%
InternalSubsts interner: #437
Region interner: #355
Stability interner: #1
Const Stability interner: #0
Allocation interner: #0
Layout interner: #0
```
|
|
|
|
comment attribution fix
comment means to refer to the macro in its direct scope
|
|
Add comments to explain memory usage optimization
Add explanatory comments so that people understand that it's just an optimization and doesn't affect behavior.
|
|
rustc_target: Further cleanup use of target options
Follow up to https://github.com/rust-lang/rust/pull/77729.
Implements items 2 and 4 from the list in https://github.com/rust-lang/rust/pull/77729#issue-500228243.
The first commit collapses uses of `target.options.foo` into `target.foo`.
The second commit renames some target options to avoid tautology:
`target.target_endian` -> `target.endian`
`target.target_c_int_width` -> `target.c_int_width`
`target.target_os` -> `target.os`
`target.target_env` -> `target.env`
`target.target_vendor` -> `target.vendor`
`target.target_family` -> `target.os_family`
`target.target_mcount` -> `target.mcount`
r? `@Mark-Simulacrum`
|
|
Assert that a return place is not used for indexing during integration
The inliner integrates call destination place with callee return place
by remapping the local and adding extra projections as necessary.
If a call destination place contains any projections (which is already
possible) and a return place is used in an indexing projection (most
likely doesn't happen yet) the end result would be incorrect.
Add an assertion to ensure that potential issue won't go unnoticed in
the presence of more sophisticated copy propagation scheme.
|
|
Make it more clear what an about async fn's returns when referring to what it returns
see #76547
This is *likely* not the ONLY place that this happens to be unclear, but we can move this fn to rustc_middle or something like that and reuse it if need be, to apply it to more diagnostics
One outstanding question I have is, if the fn returns (), should I make the message more clear (what about `fn f()` vs `fn f() -> ()`, can you tell those apart in the hir?)
R? `@tmandry`
`@rustbot` modify labels +A-diagnostics +T-compiler
|
|
* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
functions with inline hint.
|
|
|
|
Monomorphize a type argument of size-of operation during codegen
This wasn't necessary until MIR inliner started to consider drop glue as
a candidate for inlining; introducing for the first time a generic use
of size-of operation.
No test at this point since this only happens with a custom inlining
threshold.
|
|
fix `super_visit_with` for `Terminator`
fixes https://github.com/rust-lang/rust/pull/78182#discussion_r509265149
r? `@oli-obk`
cc `@LeSeulArtichaut`
|
|
rustc_ast: Do not panic by default when visiting macro calls
Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them.
The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
|
|
inliner: Break inlining cycles
Keep track of all instances inlined so far. When examining a new call
sites from an inlined body, skip those where callee had been inlined
already to avoid potential inlining cycles.
Fixes #78573.
|
|
Update Chalk to 0.36.0
This PR updates Chalk and fixes a number of bugs in the chalk integration code.
cc `@rust-lang/wg-traits`
r? `@nikomatsakis`
|
|
Improve lifetime name annotations for closures & async functions
* Don't refer to async functions as "generators" in error output
* Where possible, emit annotations pointing exactly at the `&` in the return type of closures (when they have explicit return types) and async functions, like we do for arguments.
Addresses #74072, but I wouldn't call that *closed* until annotations are identical for async and non-async functions.
* Emit a better annotation when the lifetime doesn't appear in the full name type, which currently happens for opaque types like `impl Future`. Addresses #74497, but further improves could probably be made (why *doesn't* it appear in the type as `impl Future + '1`?)
This is included in the same PR because the changes to `give_name_if_anonymous_region_appears_in_output` would introduce ICE otherwise (it would return `None` in cases where it didn't previously, which then gets `unwrap`ped)
|
|
|
|
|
|
comment means to refer to the macro in its direct scope
|
|
Implement destructuring assignment for tuples
This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909, tracking issue: #71126). This PR is the first part of #71156, which was split up to allow for easier review.
Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple.
It is implemented via a desugaring (AST -> HIR lowering) as follows:
```rust
(a,b) = (1,2)
```
... becomes ...
```rust
{
let (lhs0,lhs1) = (1,2);
a = lhs0;
b = lhs1;
}
```
Thanks to `@varkor` who helped with the implementation, particularly around default binding modes.
r? `@petrochenkov`
|
