-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rollup of 14 pull requests #81102
Closed
Closed
Rollup of 14 pull requests #81102
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
The core issue was the usage of `reference_file_path.file_name()`, which provided a non-existent path if the file to be updated was in a subdirectory. Instead we have to provide the whole path after 'tests/ui/' as the 'filename'. This part of the path is called `test_name` in the code now.
This should make the code slightly more understandable
fixes rust-lang#6522 changelog: field_reassign_with_default: don't expand macros in lint suggestion (rust-lang#6522)
Update CHANGELOG for Rust 1.50 changelog: none r? `@flip1995`
field_reassign_with_default: don't expand macros in suggestion fixes rust-lang#6522 changelog: field_reassign_with_default: don't expand macros in lint suggestion (rust-lang#6522)
Ensure `Copy` exception in trait definition for `wrong_self_conventio… Add a test case to ensure `Copy` exception is preserved also in trait definition, when passing `self` by value. Follow up of rust-lang#6316 changelog: none
Fix blessing of test output in subdirectories The core issue was the usage of `reference_file_path.file_name()`, which provided a non-existent path if the file to be updated was in a subdirectory. Instead we have to provide the whole path after 'tests/ui/' as the 'filename'. This part of the path is called `test_name` in the code now. changelog: none
… enable/disable it particularly This splits up clippy::collapsible_if into collapsible_if for if x { if y { } } => if x && y { } and collapsible_else_if for if x { } else { if y { } } => if x { } else if y { } so that we can lint for only the latter but not the first if we desire. changelog: collapsible_if: split up linting for if x {} else { if y {} } into collapsible_else_if lint
collapsible_if: split collapsible_else_if into its own lint so we can enable/disable it particularly This splits up clippy::collapsible_if into collapsible_if for if x { if y { } } => if x && y { } and collapsible_else_if for if x { } else { if y { } } => if x { } else if y { } so that we can lint for only the latter but not the first if we desire. changelog: collapsible_if: split up linting for if x {} else { if y {} } into collapsible_else_if lint
Needless Question Mark Lint Fixes rust-lang#6410, i.e the needless question mark lint changelog: [`needless_question_mark`] New lint
Add ui-internal to cargo dev bless changelog: internal
correctly deal with late-bound lifetimes in anon consts adds support for using late bound lifetimes of the parent context in anon consts. ```rust #![feature(const_generics)] const fn inner<'a>() -> usize where &'a (): Sized { 3 } fn test<'a>() { let _: [u8; inner::<'a>()]; } ``` The lifetime `'a` is late bound in `test` so it's not included in its generics but is instead dealt with separately in borrowck. This didn't previously work for anon consts as they have to use the late bound lifetimes of their parent which has to be explicitly handled. r? `@matthewjasper` cc `@varkor` `@eddyb`
resolve: Reject ambiguity built-in attr vs different built-in attr Fixes rust-lang#79798. Resolution ensures that inert attributes cannot be used through imports like this, but built-in attributes don't go through initial resolution (only through resolution validation), so we have to keep some extra data (the built-in attribute name) to prevent it from happening.
…mbol, r=nikomatsakis` Improve diagnostics when closure doesn't meet trait bound Improves the diagnostics when closure doesn't meet trait bound by modifying `TypeckResuts::closure_kind_origins` such that `hir::Place` is used instead of `Symbol`. Using `hir::Place` to describe which capture influenced the decision of selecting a trait a closure satisfies to (Fn/FnMut/FnOnce, Copy) allows us to show precise path in the diagnostics when `capture_disjoint_field` feature is enabled. Closes rust-lang/project-rfc-2229/issues/21 r? `@nikomatsakis`
… r=nikomatsakis Allow Trait inheritance with cycles on associated types take 2 This reverts the revert of rust-lang#79209 and fixes the ICEs that's occasioned by that PR exposing some problems that are addressed in rust-lang#80648 and rust-lang#79811. For easier review I'd say, check only the last commit, the first one is just a revert of the revert of rust-lang#79209 which was already approved. This also could be considered part or the actual fix of rust-lang#79560 but I guess for that to be closed and fixed completely we would need to land rust-lang#80648 and rust-lang#79811 too. r? `@nikomatsakis` cc `@Aaron1011`
…ewjasper resolve: Simplify collection of traits in scope "Traits in scope" for a given location are collected by walking all scopes in type namespace, collecting traits in them and pruning traits that don't have an associated item with the given name and namespace. Previously we tried to prune traits using some kind of hygienic resolution for associated items, but that was complex and likely incorrect, e.g. in rust-lang#80762 correction to visibilites of trait items caused some traits to not be in scope anymore. I previously had some comments and concerns about this in rust-lang#65351. In this PR we are doing some much simpler pruning based on `Symbol` and `Namespace` comparisons, it should be enough to throw away 99.9% of unnecessary traits. It is not necessary for pruning to be precise because for trait aliases, for example, we don't do any pruning at all, and precise hygienic resolution for associated items needs to be done in typeck anyway. The somewhat unexpected effect is that trait imports introduced by macros 2.0 now bring traits into scope due to the removed hygienic check on associated item names. I'm not sure whether it is desirable or not, but I think it's acceptable for now. The old check was certainly incorrect because macros 2.0 did bring trait aliases into scope. If doing this is not desirable, then we should come up with some other way to avoid bringing traits from macros 2.0 into scope, that would accommodate for trait aliases as well. --- The PR also contains a couple of pure refactorings - Scope walk is done by using `visit_scopes` instead of a hand-rolled version. - Code is restructured to accomodate for rustdoc that also wants to query traits in scope, but doesn't want to filter them by associated items at all. r? `@matthewjasper`
Use PlaceRef projection abstractions more consistently in rustc_mir PlaceRef contains abstractions for dealing with the `projections` array. This PR uses these abstractions more consistently within the `rustc_mir` crate. See associated issue: rust-lang#80647. r? `@RalfJung`
…k-Simulacrum Allow downloading LLVM on Windows and MacOS - Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked statically - Add `link-type.txt` so bootstrap knows whether llvm was linked statically or dynamically - Don't assume CI LLVM is linked dynamically in `bootstrap::config` - Fall back to dynamic linking if `link-type.txt` doesn't exist - Fix existing bug that split the output of `llvm-config` on lines, not spaces - Only special case MacOS when dynamic linking. Static linking works fine. - Enable building LLVM tests This works around the following llvm bug: ``` llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles" ``` I'm not sure why llvm-config thinks these are required, but to avoid the error, this builds them anyway. - Bump version of `download-ci-llvm-stamp` `src/llvm-project` hasn't changed, but the generated tarball has. Fixes rust-lang#77084. # Current Status This works on both MacOS and Windows! 🎉 🎉 Thanks to `@nagisa,` `@halkcyon,` `@Lokathor,` `@jryans,` and `@poliorcetics` for helping me test! The `if-available` check now supports all tier 1 platforms. Although only x64 apple and x64 msvc have been tested, none of the changes here are Windows or Mac specific, and I expect this to work anywhere that LLVM artifacts are uploaded to CI (i.e. the `rust-dev` component exists). ## Windows Note that if you have an old version of MSVC build tools you'll need to update them. VS Build Tools 2019 14.28 and later are known to work. With old tools, you may see an error like the following: ``` error LNK2001: unresolved external symbol __imp___std_init_once_complete ```
…-schievink Update rust-analyzer to https://github.com/rust-analyzer/rust-analyzer/releases/tag/2021-01-11
Update Clippy Biweekly Clippy update r? `@Manishearth`
…k, r=jyn514 Support non-stage0 check Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail). Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly. r? `@jyn514`
rustc_parse_format: Fix character indices in find_skips Fixes rust-lang#81006
…ark-Simulacrum BTreeMap: clean up a few more comments And mark `pop` as unsafe. r? `@Mark-Simulacrum`
Use Option::map instead of open-coding it r? `@oli-obk` `@rustbot` modify labels +C-cleanup +T-compiler
Use Option::unwrap_or instead of open-coding it r? `@oli-obk` Noticed this while we were talking about the other PR just now 😆 `@rustbot` modify labels +C-cleanup +T-compiler
@bors r+ p=14 rollup=never |
📌 Commit 576c3d5 has been approved by |
bors
added
the
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
label
Jan 16, 2021
⌛ Testing commit 576c3d5 with merge f0a29744440efaaec96bcdb95cd72275f82895b1... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
and removed
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Jan 17, 2021
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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.
Successful merges:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup