forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 0
Eiiv2 #7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
jdonszelmann
wants to merge
1,323
commits into
master
Choose a base branch
from
eiiv2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Eiiv2 #7
Conversation
This file contains hidden or 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
2cf200f
to
f1a38e2
Compare
…i-obk Fix up partial res of segment in primitive resolution hack There is a hack in the resolver: ``` // In `a(::assoc_item)*` `a` cannot be a module. If `a` does resolve to a module we // don't report an error right away, but try to fallback to a primitive type. ``` This fixes up the resolution for primitives which would otherwise resolve to a module, but we weren't also updating the res of the path segment, leading to weird diagnostics. We explicitly call `self.r.partial_res_map.insert` instead of `record_partial_res` b/c we have recorded a partial res already, and we specifically want to override it. cc rust-lang#139095 (comment)
Detect and provide suggestion for `&raw EXPR` When emitting an error in the parser, and we detect that the previous token was `raw` and we *could* have consumed `const`/`mut`, suggest that this may have been a mistyped raw ref expr. To do this, we add `const`/`mut` to the expected token set when parsing `&raw` as an expression (which does not affect the "good path" of parsing, for the record). This is kind of a rudimentary error improvement, since it doesn't actually attempt to recover anything, leading to some other knock-on errors b/c we still treat `&raw` as the expression that was parsed... but at least we add the suggestion! I don't think the parser grammar means we can faithfully recover `&raw EXPR` early, i.e. during `parse_expr_borrow`. Fixes rust-lang#133231
Visit place in `BackwardIncompatibleDropHint` statement Remove a weird hack from the `LocalUpdater` where we were manually visiting the place stored in a `StatementKind::BackwardIncompatibleDropHint` because the MIR visitor impls weren't doing so. Also, clean up `BackwardIncompatibleDropHint`s in `CleanupPostBorrowck`, since they're not needed for runtime MIR.
…lcnr Remove `define_debug_via_print` for `ExistentialProjection`, use regular structural debug impl The pretty print impl for `ExistentialProjection` always prints `AssocItem = Ty`: https://github.com/rust-lang/rust/blob/6e830462330a9e34d8176e86d4580dd0820c6fd5/compiler/rustc_middle/src/ty/print/pretty.rs#L3293-L3299 We can't change this, b/c it's used for both pretty printing dyn types and for legacy symbol mangling. Unfortunately, we also use this printing procedure for `Debug` impls. That means that it leaves out the *trait name* and *trait args* when debug printing an `ExistentialProjection` (or an `ExistentialPredicate` which has a variant for `ExistentialProjection`). This leads to awkward situations, like the two seemingly identical existential projection predicates present in a `dyn Trait` type using the definition below: ```rust trait Super { type Assoc; } trait Foo: Super<A, Assoc = i32> + Super<B, Assoc = i32> {} ``` Namely, they both just render as `Projection(Assoc = i32)`! This makes debugging `dyn Trait` type system bugs really hard, so let's use the *regular* debug impl for `ExistentialProjection`.
ptr docs: add missing backtics around 'usize' We almost always have the backticks, except here... so let's just fix that. Barely worth a PR but it's user-visible docs so here we go.
Add myself to mailmap
use `realpath` in `bootstrap.py` when creating build-dir Fixes rust-lang#139800 r? `@jieyouxu` My use case for `./build` being a symlink is this: my "default" ~~partition~~ btrfs subvolume is snapshotted/backed up. I don't want to backup target-likes, so I move them to a special subvolume which isn't backed up. `./build` is a symlink into that subvolume. (`build.build-dir` configuration is not fully sufficient, it is still nice to be able to check build files with `ls ./build` or call tools from there)
…r=marcoieni Improve wording of post-merge report Slight changes to improve the rendered output e.g. [here](rust-lang#139241 (comment)) if only doctest changes were found. r? `@marcoieni`
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#139127 (Fix up partial res of segment in primitive resolution hack) - rust-lang#139392 (Detect and provide suggestion for `&raw EXPR`) - rust-lang#139767 (Visit place in `BackwardIncompatibleDropHint` statement) - rust-lang#139777 (Remove `define_debug_via_print` for `ExistentialProjection`, use regular structural debug impl) - rust-lang#139796 (ptr docs: add missing backtics around 'usize') - rust-lang#139801 (Add myself to mailmap) - rust-lang#139804 (use `realpath` in `bootstrap.py` when creating build-dir) - rust-lang#139807 (Improve wording of post-merge report) r? `@ghost` `@rustbot` modify labels: rollup
This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized. Fixes rust-lang#139803
…ns` can upgrade to it
re-use `Sized` fast-path There's an existing fast path for the `type_op_prove_predicate` predicate, checking for trivially `Sized` types, which can be re-used when evaluating obligations within queries. This should improve performance and was found to be beneficial in rust-lang#137944. r? types
…, r=joboet Avoid unused clones in `Cloned<I>` and `Copied<I>` Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`. r? libs-api
opt-dist: use executable-extension for host llvm-profdata because it's used for target llvm-profdata too r? Kobzol
…lcnr Add test for issue 34834 closes: rust-lang#34834 This PR adds a UI test for a case where a trait with an associated type using a higher-ranked trait bound (HRTB) failed to compile in Rust 1.55.0 but succeeded starting from 1.56.0. ```rust pub trait Provides<'a> { type Item; } pub trait Selector: for<'a> Provides<'a> { type Namespace: PartialEq + for<'a> PartialEq<<Self as Provides<'a>>::Item>; fn get_namespace(&self) -> <Self as Provides>::Item; } pub struct MySelector; impl<'a> Provides<'a> for MySelector { type Item = &'a str; } impl Selector for MySelector { type Namespace = String; fn get_namespace(&self) -> &str { unimplemented!() } } fn main() {} ``` * ❌ [compile fail (rustc: 1.55.0)](https://godbolt.org/z/T1jY1Ebo6) * ⭕ [compile pass (rustc: 1.56.0)](https://godbolt.org/z/e4jo11Ma7)
Use `compiletest-ignore-dir` for bootstrap self-tests Follow-up to rust-lang#139705 and rust-lang#139740. I did another survey pass over `//@ ignore-test` under `tests/`, and this is the only 2 non-tests that should use `compiletest-ignore-dir`. r? `@Zalathar` (or compiler/bootstrap)
…gross35 Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can upgrade to it tracking issue: rust-lang#138997 Per rust-lang#134213 (comment), we want to make the `#[naked]` attribute an unsafe attribute. Making that change runs into a cyclic dependency with `compiler-builtins` which uses `#[naked]`, where `rustc` needs an updated `compiler-builtins` and vice versa. So based on rust-lang#139753 and [#t-compiler/help > updating &rust-lang#96;compiler-builtins&rust-lang#96; and &rust-lang#96;rustc&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/updating.20.60compiler-builtins.60.20and.20.60rustc.60), this PR allows, but does not require `#[unsafe(naked)]`, and makes that change for some of the tests to check that both `#[naked]` and `#[unsafe(naked)]` are accepted. Then we can upgrade and synchronize `compiler-builtins`, and then make `#[naked]` (without `unsafe`) invalid. r? `@traviscross` (or someone from t-compiler if you're faster and this look allright)
Specify `--print info=file` syntax in `--help` Closes rust-lang#139794 I moved the listing of information that can be printed to the help string as it's getting rather long and it makes the `[=FILE]` part easier to see
…li-obk Use `newtype_index!`-generated types more idiomatically Continuation of sorts of rust-lang#139674 Shouldn't affect anything, just makes some code simpler
Miri subtree update r? `@ghost` Fixes build failures on macOS
From `hir::AssocItem`.
Because all the other similar methods are on `AssocItem`.
To accurately reflect that RPITIT assoc items don't have a name. This avoids the use of `kw::Empty` to mean "no name", which is error prone. Helps with rust-lang#137978.
This removes E0773 "A builtin-macro was defined more than once."
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.