| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
|
|
Fixes #118242
|
|
Rollup of 7 pull requests
Successful merges:
- #118187 (Recompile LLVM when it changes in the git sources)
- #118210 (intercrate ambiguity causes: ignore candidates which don't apply)
- #118215 (Add common trait for crate definitions)
- #118238 (memcpy assumptions: update GCC link)
- #118243 (EvalCtxt::commit_if_ok don't inherit nested goals)
- #118245 (Add `Span` to `TraitBoundModifier`)
- #118246 (Remove a hack for effects)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `Span` to `TraitBoundModifier`
This improves diagnostics for the message "`~const` is not allowed here", and also fixes the span that we use when desugaring `~const Tr` into `Tr<host>` in effects desugaring.
|
|
Add common trait for crate definitions
In stable mir, we specialize DefId, however some functionality is the same for every definition, such as def paths, and getting their crate. Use a trait to implement those.
|
|
r=compiler-errors
intercrate ambiguity causes: ignore candidates which don't apply
r? `@compiler-errors`
|
|
feat: make `let_binding_suggestion` more reasonable
This is my first PR for rustc, which trying to fix https://github.com/rust-lang/rust/issues/117894, I am not familiar with some internal api so maybe some modification here isn't the way to go, appreciated for any review suggestion.
|
|
|
|
Sort unstable items last in rustdoc, instead of first
As far as I can tell, this is a bug introduced inadvertently by https://github.com/rust-lang/rust/pull/77817 in Rust 1.49. Older toolchains used to sort unstable items last.
Notice how in the code before that PR, `(Unstable, Stable) => return Ordering::Greater` in src/librustdoc/html/render/mod.rs. Whereas after that PR, `(Unstable, Stable) => return Ordering::Less`.
Compare https://doc.rust-lang.org/1.48.0/std/marker/index.html vs https://doc.rust-lang.org/1.49.0/std/marker/index.html.
|
|
rustdoc: rename `issue-\d+.rs` tests to have meaningful names (part 4)
Follow up
* https://github.com/rust-lang/rust/pull/116214
* https://github.com/rust-lang/rust/pull/116432
* https://github.com/rust-lang/rust/pull/116824
|
|
|
|
|
|
|
|
|
|
Don't print "private fields" on empty tuple structs
Closes #118180.
While working on this I also noticed that empty struct variants are also rendered rather awkwardly. I'll make another issue for that, since I don't know what the correct rendering would be.
|
|
|
|
Test for presence rather than absence
Remove redundant tests
Issues in those parts will likely be caught by other parts of the test suite.
|
|
In accordance with the [process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).
Detailed description of the feature can be found in the RFC repo - https://github.com/rust-lang/rfcs/pull/3530.
|
|
|
|
|
|
Rework supertrait lint once again
I accidentally pushed the wrong commits because I totally didn't check I was on the right computer when updating #118026.
Sorry, this should address all the nits in #118026.
r? lcnr
|
|
improve tool-only help for multiple `#[default]` variants
When defining an enum with multiple `#[default]` variants, we emit a tool-only suggestion for every `#[default]`ed variant to remove all other `#[default]`s. This PR improves the suggestion to correctly handle the cases where one variant has multiple `#[default]`s and where different `#[default]`s have the same span due to macro expansions.
fixes https://github.com/rust-lang/rust/issues/118119
|
|
When failing to import `core`, suggest `std`
|
|
|
|
We currently provide only a `help` message, this PR introduces the last
two structured suggestions instead:
```
error[E0308]: mismatched types
--> $DIR/issue-98982.rs:2:5
|
LL | fn foo() -> i32 {
| --- expected `i32` because of return type
LL | / for i in 0..0 {
LL | | return i;
LL | | }
| |_____^ expected `i32`, found `()`
|
note: the function expects a value to always be returned, but loops might run zero times
--> $DIR/issue-98982.rs:2:5
|
LL | for i in 0..0 {
| ^^^^^^^^^^^^^ this might have zero elements to iterate on
LL | return i;
| -------- if the loop doesn't execute, this value would never get returned
help: return a value for the case when the loop has zero elements to iterate on
|
LL ~ }
LL ~ /* `i32` value */
|
help: otherwise consider changing the return type to account for that possibility
|
LL ~ fn foo() -> Option<i32> {
LL | for i in 0..0 {
LL ~ return Some(i);
LL ~ }
LL ~ None
|
```
Fix #98982.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #118012 (Add support for global allocation in smir)
- #118013 (Enable Rust to use the EHCont security feature of Windows)
- #118100 (Enable profiler in dist-powerpc64-linux)
- #118142 (Tighten up link attributes for llvm-wrapper bindings)
- #118147 (Fix some unnecessary casts)
- #118161 (Allow defining opaques in `check_coroutine_obligations`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Allow defining opaques in `check_coroutine_obligations`
In the new trait solver, when an obligation stalls on an unresolved coroutine witness, we will stash away the *root* obligation, even if the stalled obligation is only a distant descendent of the root obligation, since the new solver is purely recursive.
This means that we may need to reprocess alias-relate obligations (and others) which may define opaque types in the new solver. Currently, we use the coroutine's def id as the defining anchor in `check_coroutine_obligations`, which will allow defining no opaque types, resulting in errors like:
```
error[E0271]: type mismatch resolving `{coroutine@<source>:6:5: 6:17} <: impl Clone`
--> <source>:6:5
|
6 | / move |_: ()| {
7 | | let () = yield ();
8 | | }
| |_____^ types differ
```
So this PR fixes the defining anchor and does the same trick as `check_opaque_well_formed`, where we manually compare opaques that were defined against their hidden types to make sure they weren't defined differently when processing these stalled coroutine obligations.
r? `@lcnr` cc `@cjgillot`
|
|
Enable Rust to use the EHCont security feature of Windows
In the future Windows will enable Control-flow Enforcement Technology (CET aka Shadow Stacks). To protect the path where the context is updated during exception handling, the binary is required to enumerate valid unwind entrypoints in a dedicated section which is validated when the context is being set during exception handling.
The required support for EHCONT Guard has already been merged into LLVM, long ago. This change simply adds the Rust codegen option to enable it.
Relevant LLVM change: https://reviews.llvm.org/D40223
This also adds a new `ehcont-guard` option to the bootstrap config which enables EHCont Guard when building std.
We at Microsoft have been using this feature for a significant period of time; we are confident that the LLVM feature, when enabled, generates well-formed code.
We currently enable EHCONT using a codegen feature, but I'm certainly open to refactoring this to be a target feature instead, or to use any appropriate mechanism to enable it.
|
|
Add support for global allocation in smir
Add APIs to StableMir to support global allocation. Before this change, StableMir users had no API available to retrieve Allocation provenance information. They had to resource to internal APIs instead.
One example is retrieving the Allocation of an `&str`. See test for an example on how the API can be used.
|
|
|
|
|
|
Stabilize RFC3324 dyn upcasting coercion
This PR stabilize the `trait_upcasting` feature, aka https://github.com/rust-lang/rfcs/pull/3324.
The FCP was completed here: https://github.com/rust-lang/rust/issues/65991#issuecomment-1817552398.
~~And also remove the `deref_into_dyn_supertrait` lint which is now handled by dyn upcasting coercion.~~
Heavily inspired by https://github.com/rust-lang/rust/pull/101718
Fixes https://github.com/rust-lang/rust/issues/65991
|
|
|
|
Add allow-by-default lint for unit bindings
### Example
```rust
#![warn(unit_bindings)]
macro_rules! owo {
() => {
let whats_this = ();
}
}
fn main() {
// No warning if user explicitly wrote `()` on either side.
let expr = ();
let () = expr;
let _ = ();
let _ = expr; //~ WARN binding has unit type
let pat = expr; //~ WARN binding has unit type
let _pat = expr; //~ WARN binding has unit type
// No warning for let bindings with unit type in macro expansions.
owo!();
// No warning if user explicitly annotates the unit type on the binding.
let pat: () = expr;
}
```
outputs
```
warning: binding has unit type `()`
--> $DIR/unit-bindings.rs:17:5
|
LL | let _ = expr;
| ^^^^-^^^^^^^^
| |
| this pattern is inferred to be the unit type `()`
|
note: the lint level is defined here
--> $DIR/unit-bindings.rs:3:9
|
LL | #![warn(unit_bindings)]
| ^^^^^^^^^^^^^
warning: binding has unit type `()`
--> $DIR/unit-bindings.rs:18:5
|
LL | let pat = expr;
| ^^^^---^^^^^^^^
| |
| this pattern is inferred to be the unit type `()`
warning: binding has unit type `()`
--> $DIR/unit-bindings.rs:19:5
|
LL | let _pat = expr;
| ^^^^----^^^^^^^^
| |
| this pattern is inferred to be the unit type `()`
warning: 3 warnings emitted
```
This lint is not triggered if any of the following conditions are met:
- The user explicitly annotates the binding with the `()` type.
- The binding is from a macro expansion.
- The user explicitly wrote `let () = init;`
- The user explicitly wrote `let pat = ();`. This is allowed for local lifetimes.
### Known Issue
It is known that this lint can trigger on some proc-macro generated code whose span returns false for `Span::from_expansion` because e.g. the proc-macro simply forwards user code spans, and otherwise don't have distinguishing syntax context compared to non-macro-generated code. For those kind of proc-macros, I believe the correct way to fix them is to instead emit identifers with span like `Span::mixed_site().located_at(user_span)`.
Closes #71432.
|
|
Aka trait_upcasting feature.
And also adjust the `deref_into_dyn_supertrait` lint.
|
|
Queries cleanups
r? `@bjorn3`
|
|
Remove `feature` from the list of well known check-cfg name
This PR removes `feature` from the list of well known check-cfg.
This is done for multiple reasons:
- Cargo is the source of truth, rustc shouldn't have any knowledge of it
- It creates a conflict between Cargo and rustc when there are no features defined.
In this case Cargo won't pass any `--check-cfg` for `feature` since no feature will ever be passed, but rustc by having in it's list adds a implicit `cfg(feature, values(any()))` which is completely wrong. Having any cfg `feature` is unexpected not allow any `feature` value.
While doing this, I took the opportunity to specialise the diagnostic a bit for the case above.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
|
|
|
|
There is no real need for them to be separate.
|
|
And remove the relevant getters on `Compiler` and `Queries`.
|
|
|
|
|
|
Don't ICE when ambiguity is found when selecting `Index` implementation in typeck
Fixes #118111
The problem here is when we're manually "selecting" an impl for `base_ty: Index<?0>`, we don't consider placeholder region errors (leak check) or ambiguous predicates. Those can lead to us not actually emitting any fulfillment errors on line 3131.
|
