Conversation
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Since we support solaris 11 and macOs Sierra as minimum, we can get rid of the runtime overhead.
For PGO/coverage tests that don't need to build or run an actual artifact, we can use `-Zno-profiler-runtime` to run the test even when the profiler runtime is not available.
The profiler runtime is no longer built in mingw test jobs, so these tests should naturally be skipped by `//@ needs-profiler-support`.
Don't build a broken/untested profiler runtime on mingw targets Context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Why.20build.20a.20broken.2Funtested.20profiler.20runtime.20on.20mingw.3F rust-lang#75872 added `--enable-profiler` to the `x86_64-mingw` job (to cause some additional tests to run), but had to also add `//@ ignore-windows-gnu` to all of the tests that rely on the profiler runtime actually *working*, because it's broken on that target. We can achieve a similar outcome by going through all the `//@ needs-profiler-support` tests that don't actually need to produce/run a binary, and making them use `-Zno-profiler-runtime` instead, so that they can run even in configurations that don't have the profiler runtime available. Then we can remove `--enable-profiler` from `x86_64-mingw`, and still get the same amount of testing. This PR also removes `--enable-profiler` from the mingw dist builds, since it is broken/untested on that target. Those builds have had that flag for a very long time.
change method resolution to constrain hidden types instead of rejecting method candidates
Some of these are in probes and may affect inference. This is therefore a breaking change.
This allows new code to compile on stable:
```rust
trait Trait {}
impl Trait for u32 {}
struct Bar<T>(T);
impl Bar<u32> {
fn foo(self) {}
}
fn foo(x: bool) -> Bar<impl Sized> {
if x {
let x = foo(false);
x.foo();
//^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
}
todo!()
}
```
r? `@compiler-errors`
fixes rust-lang#121404
cc rust-lang#116652
[1/2] clean-up / general improvements This PR applies various clippy suggestions on the tools. I have only applied the ones that make sense and left out trivial changes (e.g., suggestions like 'remove &' are ignored to keep the original commit history for the lines). I am planning to do the same for the library and compiler, but those will add too many changes to this PR, so I will handle them in a separate PR later.
Avoid ICES after reporting errors on erroneous patterns fixes rust-lang#109812 fixes rust-lang#125914 fixes rust-lang#124004
std::unix::fs::link using direct linkat call for Solaris. Since we support solaris 11 as minimum, we can get rid of the runtime overhead. try-job: dist-various-2
|
@bors r+ rollup=never p=5 |
|
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message |
|
☔ The latest upstream changes (presumably #126396) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup