| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix dupe word typos
|
|
Add small comment explaining what `method-margins.goml` test is about
r? `````@notriddle`````
|
|
Fix UI issues with Rustdoc scrape-examples feature.
A few regressions have been introduced into scrape-examples in the last few months. This commit fixes those regressions:
* Help file was being loaded from the wrong place (introduced in f9e1f6ffdf03ec33cb29e20c88fc7bcc938c7f42).
* CSS selector in JS has a typo (introduced in 14897180ae6a0506a5ad0a9f6a30ae1f75916179).
* Line numbers in scraped example code snippets are overflowing (not sure if this was ever fixed). Changing from flexbox to grid display fixed this issue.
|
|
Disable top down MIR inlining
The current MIR inliner has exponential behavior in some cases: <https://godbolt.org/z/7jnWah4fE>. The cause of this is top-down inlining, where we repeatedly do inlining like `call_a() => { call_b(); call_b(); }`. Each decision on its own seems to make sense, but the result is exponential.
Disabling top-down inlining fundamentally prevents this. Each call site in the original, unoptimized source code is now considered for inlining exactly one time, which means that the total growth in MIR size is limited to number of call sites * inlining threshold.
Top down inlining may be worth re-introducing at some point, but it needs to be accompanied with a principled way to prevent this kind of behavior.
|
|
|
|
attribute.
Compiler MCP:
https://github.com/rust-lang/compiler-team/issues/565
|
|
This ensures that the error is printed even for unused variables,
as well as unifying the handling between the LLVM and GCC backends.
This also fixes unusual behavior around exported Rust-defined variables
with linkage attributes. With the previous behavior, it appears to be
impossible to define such a variable such that it can actually be imported
and used by another crate. This is because on the importing side, the
variable is required to be a pointer, but on the exporting side, the
type checker rejects static variables of pointer type because they do
not implement `Sync`. Even if it were possible to import such a type, it
appears that code generation on the importing side would add an unexpected
additional level of pointer indirection, which would break type safety.
This highlighted that the semantics of linkage on Rust-defined variables
is different to linkage on foreign items. As such, we now model the
difference with two different codegen attributes: linkage for Rust-defined
variables, and import_linkage for foreign items.
This change gives semantics to the test
src/test/ui/linkage-attr/auxiliary/def_illtyped_external.rs which was
previously expected to fail to compile. Therefore, convert it into a
test that is expected to successfully compile.
The update to the GCC backend is speculative and untested.
|
|
When *any* of the suggested impls is an exact match, *only* show the
exact matches. This is particularly relevant for integer types.
fix fmt
|
|
|
|
This code uses a special `hideme` class anyway, so just style that.
|
|
Skip recording resolution for duplicated generic params.
Turns out the fix was simpler than I thought.
Fixes https://github.com/rust-lang/rust/issues/104312
|
|
suggest parenthesis around ExprWithBlock BinOp ExprWithBlock
fix https://github.com/rust-lang/rust/issues/105179
fix https://github.com/rust-lang/rust/issues/102171
|
|
Use proper HirId for async track_caller attribute check
Fix #105134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoid some `InferCtxt::build` calls
Either because we're inside of an `InferCtxt` already, or because we're not in a place where we'd ever see inference vars.
r? types
|
|
|
|
Make sure async constructs do not `impl Generator`
Async lowering turns async functions and blocks into generators internally.
Though these special kinds of generators should not `impl Generator` themselves.
The other way around, normal generators should not `impl Future`.
This was discovered in https://github.com/rust-lang/rust/pull/105082#issuecomment-1332210907 and is a regression from https://github.com/rust-lang/rust/pull/104321.
r? `@compiler-errors`
|
|
rustc_codegen_ssa: Fix for codegen_get_discr
When doing the optimized implementation of getting the discriminant, the arithmetic needs to be done in the tag type so wrapping behavior works correctly.
Fixes #104519
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #101975 (Suggest to use . instead of :: when accessing a method of an object)
- #105141 (Fix ICE on invalid variable declarations in macro calls)
- #105224 (Properly substitute inherent associated types.)
- #105236 (Add regression test for #47814)
- #105247 (Use parent function WfCheckingContext to check RPITIT.)
- #105253 (Update a couple of rustbuild deps)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use parent function WfCheckingContext to check RPITIT.
WF-check for RPITIT was done in the opaque type's param-env, so it could not benefit from assumed wf types from the function's parameters.
cc `@compiler-errors` since you chose that param-env in fd2766e7fde4
Fixes https://github.com/rust-lang/rust/issues/102682
Fixes https://github.com/rust-lang/rust/issues/104908
Fixes https://github.com/rust-lang/rust/issues/102552
Fixes https://github.com/rust-lang/rust/issues/104529
|
|
Add regression test for #47814
Closes #47814
r? `@compiler-errors`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Properly substitute inherent associated types.
Fixes https://github.com/rust-lang/rust/issues/104240
|
|
r=compiler-errors
Fix ICE on invalid variable declarations in macro calls
This fixes ICE that happens with invalid variable declarations in macro calls like:
```rust
macro_rules! m { ($s:stmt) => {} }
m! { var x }
m! { auto x }
m! { mut x }
```
Found this is because of not collecting tokens on recovery, so I changed to force collect them.
Fixes https://github.com/rust-lang/rust/issues/103529.
|
|
Suggest to use . instead of :: when accessing a method of an object
Fixes #101749
Fixes #101542
|
|
|
|
|
|
Remove drop order twist of && and || and make them associative
Previously a short circuiting binop chain (chain of && or ||s) would drop the temporaries created by the first element after all the other elements, and otherwise follow evaluation order. So `f(1).g() && f(2).g() && f(3).g() && f(4).g()` would drop the temporaries in the order `2,3,4,1`. This made `&&` and `||` non-associative regarding drop order. In other words, adding ()'s to the expression would change drop order: `f(1).g() && (f(2).g() && f(3).g()) && f(4).g()` for example would drop in the order `3,2,4,1`.
As, except for the bool result, there is no data returned by the sub-expressions of the short circuiting binops, we can safely discard of any temporaries created by the sub-expr. Previously, code was already putting the rhs's into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". We now also put the lhs into a terminating scope. The drop order of the above expressions becomes `1,2,3,4`.
There might be code relying on the current order, and therefore I'd recommend doing a crater run to gauge the impact. I'd argue that such code is already quite wonky as it is one `foo() &&` addition away from breaking. ~~For the impact, I don't expect any *build* failures, as the compiler gets strictly more tolerant: shortening the lifetime of temporaries only expands the list of programs the compiler accepts as valid. There might be *runtime* failures caused by this change however.~~ Edit: both build and runtime failures are possible, e.g. see the example provided by dtolnay [below](https://github.com/rust-lang/rust/pull/103293#issuecomment-1285341113). Edit2: the crater run has finished and [results](https://github.com/rust-lang/rust/pull/103293#issuecomment-1292275203) are that there is only one build failure which is easy to fix with a +/- 1 line diff.
I've included a testcase that now compiles thanks to this patch.
The breakage is also limited to drop order relative to conditionals in the && chain: that is, in code like this:
```Rust
let hello = foo().hi() && bar().world();
println!("hi");
```
we already drop the temporaries of `foo().hi()` before we reach "hi".
I'd ideally have this PR merged before let chains are stabilized. If this PR is taking too long, I'd love to have a more restricted version of this change limited to `&&`'s in let chains: the `&&`'s of such chains are quite special anyways as they accept `let` bindings, in there the `&&` is therefore more a part of the "if let chain" construct than a construct of its own.
Fixes #103107
Status: waiting on [this accepted FCP](https://github.com/rust-lang/rust/pull/103293#issuecomment-1293411354) finishing.
|
|
|
|
Add regression test for #79450
Closes #79450
r? `@oli-obk`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Make inline const block `ExprWithBlock`
Fix https://github.com/rust-lang/rust/pull/104087#issuecomment-1324190817
`@rustbot` label: +T-lang +F-inline_const
|
|
Fix passing MACOSX_DEPLOYMENT_TARGET to the linker
I messed up in https://github.com/rust-lang/rust/pull/103929 when merging the two base files together and as a result, started ignoring `MACOSX_DEPLOYMENT_TARGET` at the linker level. This ended up being the cause of nighty builds not running on older macOS versions.
My original hope with the previous PR was that CI would have caught something like that but there were only tests checking the compiler target definitions in codegen tests. Because of how badly this sucks to break, I put together a new test via `run-make` that actually confirms the deployment target set makes it to the linker instead of just LLVM.
Closes https://github.com/rust-lang/rust/issues/104570 (for real this time)
|
|
r=compiler-errors
Don't suggest associated function call for associated const.
Fixes #104801.
r? `@compiler-errors`
|
|
|
|
This avoids creation of a terminating scope in
chains that contain both && and ||, because
also there we know that a terminating scope is
not neccessary: all the chain members are already
in such terminating scopes.
Also add a mixed && / || test.
|
|
r=GuillaumeGomez,jyn514,Manishearth
Consolidate rustdoc's lint passes into a single pass
This should improve performance and simplify the code.
r? `@GuillaumeGomez`
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
|
|
Previously a short circuiting && chain would drop the
first element after all the other elements, and otherwise
follow evaluation order, so code like:
f(1).g() && f(2).g() && f(3).g() && f(4).g()
would drop the temporaries in the order 2,3,4,1. This made
&& and || non-associative regarding drop order, so
adding ()'s to the expression would change drop order:
f(1).g() && (f(2).g() && f(3).g()) && f(4).g()
for example would drop in the order 3,2,4,1.
As, except for the bool result, there is no data returned
by the sub-expressions of the short circuiting binops,
we can safely discard of any temporaries created by the
sub-expr. Previously, code was already putting the rhs's
into terminating scopes, but missed it for the lhs's.
This commit addresses this "twist". In the expression,
we now also put the lhs into a terminating scope.
The drop order for the above expressions is 1,2,3,4
now.
|
|
|
