Should trigger #8
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This lets us avoid the use of `DiagnosticBuilder::into_diagnostic` in miri, when then means that `DiagnosticBuilder::into_diagnostic` can become private, being now only used by `stash` and `buffer`.
Diagnostic API fixes Some improvements to diagnostic APIs: improve some naming, use shortcuts in more places, and add a couple of missing methods. r? `@compiler-errors`
`is_force_warn` is only possible for diagnostics with `Level::Warning`, but it is currently stored in `Diagnostic::code`, which every diagnostic has. This commit: - removes the boolean `DiagnosticId::Lint::is_force_warn` field; - adds a `ForceWarning` variant to `Level`. Benefits: - The common `Level::Warning` case now has no arguments, replacing lots of `Warning(None)` occurrences. - `rustc_session::lint::Level` and `rustc_errors::Level` are more similar, both having `ForceWarning` and `Warning`.
…iler-errors Exhaustiveness: use an `Option` instead of allocating fictitious patterns In the process of exhaustiveness checking, `Matrix` stores a 2D array of patterns. Those are subpatterns of the patterns we were provided as input, _except_ sometimes we allocate some extra wildcard patterns to fill a hole during specialization. Morally though, we could store `Option<&'p DeconstructedPat>` in the matrix, where `None` signifies a wildcard. That way we'd only have "real" patterns in the matrix and we wouldn't need the arena to allocate these wildcards. This is what this PR does. This is part of me splitting up rust-lang/rust#119581 for ease of review. r? `@compiler-errors`
Use version-sorting for all sorting Add a description of a version-sorting algorithm. (This algorithm does not precisely match `strverscmp`; it's intentionally simpler in its handling of leading zeroes, and produces a result easier for humans to easily understand and do by hand.) Change all references to sorting to use version-sorting. Change all references to "ASCIIbetically" to instead say "sort non-lowercase before lowercase".
Add some comments, add `can_define_opaque_ty` check to `try_normalize_ty_recur` Follow-up from #117278, since I was recently re-reviewing this code.
Pass LLVM error message back to pass wrapper. When rustc fails to load a plugin, it should provide more detailed error message. Before this PR, rustc prints: ``` error: failed to run LLVM passes: Failed to load pass pluginPLUGIN_NAME.so ``` This PR passes LLVM errors back to rustc. After this PR, rustc prints: ``` error: failed to run LLVM passes: Could not load library 'PLUGIN_NAME.so': PLUGIN_NAME.so: undefined symbol: _ZN4llvm9DebugFlagE ``` This PR only contains usability improvements and does not change any functionality. Thus, no new unit test is implemented.
…rrors Exhaustiveness: abort on type error This adds an error path to exhaustiveness checking so that we abort instead of ICEing when encountering a stray `ty::Error`. Fixes rust-lang/rust#119493 Fixes rust-lang/rust#119778 r? `@compiler-errors`
Cleanup things in and around `Diagnostic` These changes all arose when I was looking closely at how to simplify `DiagCtxtInner::emit_diagnostic`. r? `@compiler-errors`
change function name in comments fixes #119787 where I believe an incorrect function name is used in the comments
Fix all_trait* methods to return all traits available in StableMIR Also provide a mechanism to retrieve traits and implementations for a given crate. This fixes rust-lang/project-stable-mir#37
…ler-errors Silence some follow-up errors [1/x] this is one piece of the requested cleanups from rust-lang/rust#117449 When we use `-> impl SomeTrait<_>` as a return type, we are both using the "infer return type suggestion" code path, and the infer opaque type code path within the same function. That can lead to confusing diagnostics, so silence all opaque type diagnostics in that case.
Stabilize mutex_unpoison feature Closes #96469 `@rustbot` +T-libs-api
…mpiler-errors Meta: Add project const traits to triagebot config r? compiler-errors or project-const-traits
Rollup of 11 pull requests Successful merges: - #115046 (Use version-sorting for all sorting) - #118915 (Add some comments, add `can_define_opaque_ty` check to `try_normalize_ty_recur`) - #119006 (Fix is_global special address handling) - #119637 (Pass LLVM error message back to pass wrapper.) - #119715 (Exhaustiveness: abort on type error) - #119763 (Cleanup things in and around `Diagnostic`) - #119788 (change function name in comments) - #119790 (Fix all_trait* methods to return all traits available in StableMIR) - #119803 (Silence some follow-up errors [1/x]) - #119804 (Stabilize mutex_unpoison feature) - #119832 (Meta: Add project const traits to triagebot config) r? `@ghost` `@rustbot` modify labels: rollup
Reorder early post-inlining passes. `RemoveZsts`, `RemoveUnneededDrops` and `UninhabitedEnumBranching` only depend on types, so they should be executed together early after MIR inlining introduces those types. This does not change the end-result, but this makes the pipeline a bit more consistent.
Automatic Rustup
bump bootstrap dependencies This PR removes hard-coded patch versions, updates bootstrap's dependency stack to recent versions (some of the versions were released 3-4 years ago), and removes a few dependencies from bootstrap. Removed dependencies: 
Remove a large amount of leb128-coded integers This removes ~41%[^1] of the leb128-encoded integers serialized during libcore compilation by changing enum tags to opportunistically use `u8` where feasible instead of the leb128 coding via `usize`. This should have effectively zero impact on metadata file sizes, since almost all or all enum tags fit into the 7 bits available in leb128 for single-byte encodings. Perf results indicate this is basically neutral across the board except for an improvement in bootstrap time. [^1]: More than half the remaining integers still fit into <= 128, so the leb128 coding still makes sense. 32% are zero, and 46% are <= 4.
Update LLVM submodule Fixes rust-lang/rust#118867. Fixes rust-lang/rust#119160. Fixes rust-lang/rust#119179. r? `@cuviper`
libtest: Fix padding of benchmarks run as tests ### Summary The first commit adds regression tests for libtest padding. The second commit fixes padding for benches run as tests and updates the blessed output of the regression tests to make it clear what effect the fix has on padding. Closes #104092 which is **E-help-wanted** and **regression-from-stable-to-stable** ### More details Before this fix we applied padding _before_ manually doing what `convert_benchmarks_to_tests()` does which affects padding calculations. Instead use `convert_benchmarks_to_tests()` first if applicable and then apply padding afterwards so it becomes correct. Benches should only be padded when run as benches to make it easy to compare the benchmark numbers. Not when run as tests. r? `@ghost` until CI passes.
next solver: provisional cache this adds the cache removed in #115843. However, it should now correctly track whether a provisional result depends on an inductive or coinductive stack. While working on this, I was using the following doc: https://hackmd.io/VsQPjW3wSTGUSlmgwrDKOA. I don't think it's too helpful to understanding this, but am somewhat hopeful that the inline comments are more useful. There are quite a few future perf improvements here. Given that this is already very involved I don't believe it is worth it (for now). While working on this PR one of my few attempts to significantly improve perf ended up being unsound again because I was not careful enough ✨ r? `@compiler-errors`
This reverts commit 503e129328080e924c0ddfca6abf4c2812580102, reversing changes made to 0e7f91b75e7484a713e2f644212cfc1aa7478a28.
Check rust lints when an unknown lint is detected Fixes #118183
Add more information to `visit_projection_elem` Without the starting place, it's hard to retrieve any useful information from visiting a projection. Note: I still need to add a test.
Revert #113923 Per [#t-compiler/meetings > [weekly] 2024-01-11](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-01-11) discussion, revert #113923. Also revert associated #118568. The PR #113923 causes the regression issue #118609. We need more time to find a proper solution. Discussions start at [412365838](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-01-11/near/412365838) and continue to [412369643](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-01-11/near/412369643). Fixes #118609. r? compiler
Rollup of 6 pull requests Successful merges: - #119817 (Remove special-casing around `AliasKind::Opaque` when structurally resolving in new solver) - #119819 (Check rust lints when an unknown lint is detected) - #119872 (Give me a way to emit all the delayed bugs as errors (add `-Zeagerly-emit-delayed-bugs`)) - #119877 (Add more information to `visit_projection_elem`) - #119884 (Rename `--env` option flag to `--env-set`) - #119885 (Revert #113923) r? `@ghost` `@rustbot` modify labels: rollup
…e_nonzero, r=scottmcm Add assume into `NonZeroIntX::get` LLVM currently don't support range metadata for function arguments so it fails to optimize non zero integers using their invariant if they are provided using by-value function arguments. Related to rust-lang/rust#119422 Related to llvm/llvm-project#76628 Related to rust-lang/rust#49572
Fix unused_parens issue when cast is followed LT Fixes #117142 The original check only checks `a as (i32) < 0`, this fix extends it to handle `b + a as (i32) < 0`. A better way is maybe we suggest `(a as i32) < 0` instead of suppressing the warning, maybe following PR could improve it.
… r=petrochenkov Exclude well known names from showing a suggestion in check-cfg This PR adds an exclusion for well known names from showing in suggestions of check-cfg/`unexpected_cfgs`. Follow-up to rust-lang/rust#118213 and fixes rust-lang/rust#118213 (comment). r? `@petrochenkov`
Delegation implementation: step 1 See rust-lang/rust#118212 for more details. r? `@petrochenkov`
Add explicit `none()` value variant in check-cfg
This PR adds an explicit none value variant in check-cfg values: `values(none())`.
Currently the only way to define the none variant is with an empty `values()` which means that if someone has a cfg that takes none and strings they need to use two invocations: `--check-cfg=cfg(foo) --check-cfg=cfg(foo, values("bar"))`.
Which would now be `--check-cfg=cfg(foo, values(none(),"bar"))`, this is simpler and easier to understand.
`--check-cfg=cfg(foo)`, `--check-cfg=cfg(foo, values())` and `--check-cfg=cfg(foo, values(none()))` would be equivalent.
*Another motivation for doing this is to make empty `values()` actually means no-values, but this is orthogonal to this PR and adding `none()` is sufficient in it-self.*
`@rustbot` label +F-check-cfg
r? `@petrochenkov`
Automatic Rustup
Varargs support for system ABI This PR allows functions with the `system` ABI to be variadic (under the `extended_varargs_abi_support` feature tracked in #100189). On x86 windows, the `system` ABI is equivalent to `C` for variadic functions. On other platforms, `system` is already equivalent to `C`. Fixes #110505
rename `reported_signature_mismatch` to reflect its use it's used for a lot of things, not only closures
…ler-errors Allow `~const` on associated type bounds again This follows from [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/419616-t-compiler.2Fproject-const-traits/topic/projections.20on.20.28~.29const.20Trait.20.26.20.28~.29const.20assoc.20ty.20bounds). Basically in my opinion, it makes sense to allow `~const` on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax `<Ty as ~const Trait>::Proj`/`<Ty as const Trait>::Proj` yet; that can happen as a follow-up. This already allows more code to compile since `T::Assoc` where `T` is a type parameter and where the predicate `<T as ~const Trait>` is in the environment gets elaborated to (pseudo) `<T as ~const Trait>::Assoc`. ```rs #[const_trait] trait Trait { type Assoc: ~const Trait; fn func() -> i32; } const fn function<T: ~const Trait>() -> i32 { T::Assoc::func() } ``` `~const` associated type bounds also work together with `const` bounds: ```rs struct Type<const N: i32>; fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above Type } ``` NB: This PR also starts allowing `~const` bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them? For reference, it wouldn't make any sense to allow `~const Trait` in GACs (generic associated constants, `generic_const_items`) because they'd be absolutely useless (contrary to `const Trait`). ~~[``@]rustbot`` ping project-const-traits~~ r? project-const-traits
Taint `_` placeholder types in trait impl method signatures We report an error right below for them, but that kind of broken type can cause subsequent ICEs. fixes #119867
Remove unused `ErrorReporting` variant from overflow handling r? oli-obk
Move platform modules into `sys::pal` This is the initial step of #117276. `sys` just re-exports everything from the current `sys` for now, I'll move the implementations for the individual features one-by-one after this PR merges.
Rollup of 6 pull requests Successful merges: - #119587 (Varargs support for system ABI) - #119891 (rename `reported_signature_mismatch` to reflect its use) - #119894 (Allow `~const` on associated type bounds again) - #119896 (Taint `_` placeholder types in trait impl method signatures) - #119898 (Remove unused `ErrorReporting` variant from overflow handling) - #119902 (fix typo in `fn()` docs) r? `@ghost` `@rustbot` modify labels: rollup
…=Nilstrieb rustc_codegen_ssa: Enforce `rustc::potential_query_instability` lint Part of rust-lang/rust#84447.
Automatic Rustup
|
There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged. You can start a rebase with the following commands: The following commits are merge commits:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.