-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Rollup of 9 pull requests #143116
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Rollup of 9 pull requests #143116
Conversation
rustc_std_internal_symbol is meant to call functions from crates where there is no direct dependency on said crate. As they either have to be added to symbols.o or rustc has to introduce an implicit dependency on them to avoid linker errors. The latter is done for some things like the panic runtime, but adding these symbols to symbols.o allows removing those implicit dependencies.
This used to be necessary for a correct linker order, but ever since the introduction of symbols.o adding the symbols in question to symbols.o would work just as well. We do still add dependencies on the panic runtime to the local crate, but not for #![needs_panic_runtime] crates. This also removes the runtime-depends-on-needs-runtime test. inject_dependency_if used to emit this error, but with symbols.o it is no longer important that there is no dependency and in fact it may be nice to have panic_abort and panic_unwind directly depend on libstd in the future for calling std::process::abort().
You shouldn't ever need to explicitly depend on it. And we weren't checking that the panic runtime used the correct panic strategy either.
There is already panic-unwind to enable it.
…=fee1-dead New const traits syntax This PR only affects the AST and doesn't actually change anything semantically. All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error r? ``@fee1-dead`` cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
…trochenkov Reduce special casing for the panic runtime See the individual commits for more info.
…hen_file_found_but_module_not_defined, r=petrochenkov suggest declaring modules when file found but module not defined suggests declaring modules when a module is found but not defined, i.e ``` ├── main.rs: `use thing::thang;` └── thing.rs: `struct thang` ``` or ``` ├── main.rs: `use thing::thang;` └── thing └── mod.rs: `struct thang` ``` which currently is just ```rust error[E0432]: unresolved import `yeah` --> src/main.rs:1:1 | 1 | use thing::thang; | ^^^^^ use of unresolved module or unlinked crate `thing` | ``` but now would have this nice help: ```text = help: you may have forgotten to declare the module `thing`. use `mod thing` in this file to declare this module. ```
…lcnr,BoxyUwU Normalize before computing ConstArgHasType goal in new solver This is a fix for rust-lang#139905. See the description I left in the test. I chose to fix this by normalizing the type before matching on its `.kind()` in `compute_const_arg_has_type_goal` (since it feels somewhat consistent with how we normalize types before assembling their candidates, for example); however, there are several other solutions that come to mind for fixing this ICE: 1. (this solution) 2. Giving `ConstKind::Error` a proper type, like `ConstKind::Value`, so that consts don't go from failing to passing `ConstArgHasType` goals after normalization (i.e. `UNEVALUATED` would normalize into a `ConstKind::Error(_, bool)` type rather than losing its type altogether). 3. Just suppressing the errors and accepting the fact that goals can go from fail->pass after normalization. Thoughts? Happy to discuss this fix further. r? `@BoxyUwU`
…li-obk const validation: properly ignore zero-sized UnsafeCell Fixes rust-lang#142948 r? `@oli-obk`
… r=oli-obk const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology This error recently got changed in rust-lang#140942 to use the terminology of "top-level scope", but after further discussion in rust-lang/reference#1865 it seems the reference will not be using that terminology after all. So let's also remove it from the compiler again, and let's focus on what actually happens with these temporaries: their lifetime is extended until the end of the program. r? ``@oli-obk`` ``@traviscross``
…er-errors tag_for_variant: properly pass TypingEnv Hard-coding `fully_monomorphized` here does not seem right... This came up [on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20VariantId.3DDiscriminant.20when.20tag.20is.20niche.20encoded.3F/with/526103956).
…sized-deny, r=compiler-errors hir_analysis: prohibit `dyn PointeeSized` Fixes rust-lang#142652 Supersedes rust-lang#142663 `dyn PointeeSized` is nonsensical as a `dyn PointeeSized` needs to be `MetaSized`, so lets reject it to avoid hitting code paths that expect a builtin impl for `PointeeSized` r? `@compiler-errors`
…BoxyUwU gce: don't ICE on non-local const Fixes rust-lang#133808 I have absolutely no idea what I'm doing here, but I followed `@BoxyUwU` 's [instructions](rust-lang#133808 (comment)), and turns out this small change fixes rust-lang#133808, and doesn't seem to break anything else. (This code path is only reachable when the GCE feature gate is enabled, so even if it does break in a way that is not caught by current test coverage, I guess it's not as bad as breaking stable or non-incomplete features?) Anyways, r? `@BoxyUwU` , if you don't mind.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: bdaba05a95 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing bdaba05 (parent) -> d41e12f (this PR) Test differencesShow 72 test diffsStage 1
Stage 2
Additionally, 8 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard d41e12f1f4e4884c356f319b881921aa37040de5 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (d41e12f): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.9%, secondary 2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -1.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 689.13s -> 690.233s (0.16%) |
Successful merges:
dyn PointeeSized
#143104 (hir_analysis: prohibitdyn PointeeSized
)Failed merges:
dyn*
from the compiler #143036 (Remove support fordyn*
from the compiler)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup