-
Notifications
You must be signed in to change notification settings - Fork 386
Rustup #2842
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
Merged
Merged
Rustup #2842
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
Migrating rustc_infer to session diagnostics (part 5) `@rustbot` label +A-translation cc rust-lang/rust#100717
Add suggestion to remove `derive()` if invoked macro is non-derive Adds to the existing `expected derive macro, found {}` error message: ``` help: remove the surrounding "derive()": --> $DIR/macro-path-prelude-fail-4.rs:1:3 | LL | #[derive(inline)] | ^^^^^^^ ^ ``` This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`? Closes #109589
rustc_middle: Document which exactly `DefId`s don't have `DefKind`s I don't currently have time to investigate when and how to create these missing HIR nodes, but if someone else could do that it would be great.
Emits non-overlapping suggestions for arguments with wrong types Fixes #109831
update Miri Most importantly, this should ensure that the Miri test suite passes in this repo, when the issue is fixed. r? `@oli-obk`
rustc_metadata: Filter encoded data more aggressively using `DefKind` I focused on data that contains spans, because spans are expensive to encode/decode/hash, but also touched `should_encode_visibility` too. One incorrect use of impl visibility in diagnostics is also replaced with trait visibility.
…iler-errors Migrate most of `rustc_builtin_macros` to diagnostic impls cc #100717 This is a couple of days work, but I decided to stop for now before the PR becomes too big. There's around 50 unresolved failures when `rustc::untranslatable_diagnostic` is denied, which I'll finish addressing once this PR goes thtough A couple of outputs have changed, but in all instances I think the changes are an improvement/are more consistent with other diagnostics (although I'm happy to revert any which seem worse)
Add codegen tests for issues fixed by LLVM 16 Fixes #75978. Fixes #99960. Fixes #101048. Fixes #101082. Fixes #101814. Fixes #103132. Fixes #103327.
…jgillot incr.comp.: Make sure dependencies are recorded when feeding queries during eval-always queries. This PR makes sure we don't drop dependency edges when feeding queries during an eval-always query. Background: During eval-always queries, no dependencies are recorded because the system knows to unconditionally re-evaluate them regardless of any actual dependencies. This works fine for these queries themselves but leads to a problem when feeding other queries: When queries are fed, we set up their dependency edges by copying the current set of dependencies of the feeding query. But because this set is empty for eval-always queries, we record no edges at all -- which has the effect that the fed query instances always look "green" to the system, although they should always be "red". The fix is to explicitly add a dependency on the artificial "always red" dep-node when feeding during eval-always queries. Fixes rust-lang/rust#108481 Maybe also fixes issue rust-lang/rust#88488. cc `@jyn514` r? `@cjgillot` or `@oli-obk`
… r=wesleywiser Preserve argument indexes when inlining MIR We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining. We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index. Fixes #83217 I considered using `Option<NonZeroU16>` instead of `Option<u16>` to store the index. I didn't because `TypeFoldable` isn't implemented for `NonZeroU16` and because it looks like due to padding, it currently wouldn't make any difference. But I indexed from 1 anyway because (a) it'll make it easier if later it becomes worthwhile to use a `NonZeroU16` and because the arguments were previously indexed from 1, so it made for a smaller change. This is my first PR on rust-lang/rust, so apologies if I've gotten anything not quite right.
don't splice from files into pipes in io::copy This fixes potential data ordering issue where a write performed after a copy operation could become visible in the copy even though it signaled completion. I assumed that by not setting `SPLICE_F_MOVE` we would be safe and the kernel would do a copy in kernel space and we could avoid the read-write syscall and copy-to/from-userspace costs. But apparently that flag only makes a difference when splicing from a pipe, but not when splicing into it. Context: https://lkml.org/lkml/2023/2/9/673
…Simulacrum Stabilize IsTerminal FCP completed in rust-lang/rust#98070 . closes: rust-lang/rust#98070
Erase lifetimes above `ty::INNERMOST` when probing ambiguous types Turns out that `TyCtxt::replace_escaping_bound_vars_uncached` only erases bound vars exactly at `ty::INNERMOST`, and not everything above. This regresses the suggestions for non-lifetime binders, but oh well, I don't really care about those. Fixes #110052
Remove `ToRegionVid` r? ```@compiler-errors```
cleanup our region error API - require `TypeErrCtxt` to always result in an error, closing #108810 - move `resolve_regions_and_report_errors` to the `ObligationCtxt` - call `process_registered_region_obligations` in `resolve_regions` - move `resolve_regions` into the `outlives` submodule - add `#[must_use]` to functions returning lists of errors r? types
Fix btree `CursorMut::insert_after` check Fixes a check inside `BTreeMap`'s `CursorMut::insert_after`, where it would peek the previous element to check whether the inserted key is below the next one, instead of peeking the next element.
Update unwind_safe.rs Typo in the documentation.
Rollup of 6 pull requests Successful merges: - #110072 (Stabilize IsTerminal) - #110195 (Erase lifetimes above `ty::INNERMOST` when probing ambiguous types) - #110218 (Remove `ToRegionVid`) - #110220 (cleanup our region error API) - #110234 (Fix btree `CursorMut::insert_after` check) - #110262 (Update unwind_safe.rs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Add inline assembly support for m68k I believe this should be correct, to the extent I understand the logic around inline assembly. M68k is fairly straightforward here, other than having separate address registers.
…crum bump `futures` to use syn 2.0 cc #109302
resolve: Pre-compute non-reexport module children Instead of repeating the same logic by walking HIR during metadata encoding. The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list. They can be encoded separately if this need ever arises. `module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
Move most ui-fulldeps tests to ui/ Same rationale as rust-lang/rust#109770, they don't actually need a stage 2 build. This increases the limit for the UI directory because otherwise it was annoying to be constantly moving files into subdirectories when I fixed a test; rust-lang/rust#109873 makes up for it. cc rust-lang/rust#109770, rust-lang/rust#109874
linkat() not available in the system headers of Solaris 10 I've installed rustup on x86_64-unknown-linux-gnu and would like to use the target sparcv9-sun-solaris. For this, I have built a gcc from the source code for cross-compiling to sparcv9-sun-solaris2.10 with system headers of Solaris 10. With the following hello word example: main.rs: ```rust fn main() { println!("Hello, world!"); } ``` I had a compilation error: ``` $ rustc -v --target sparcv9-sun-solaris -C linker=/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc main.rs error: linking with `/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc` failed: exit status: 1 | = note: "/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc" "-m64" "/tmp/rustcgebYgj/symbols.o" "main.main.89363361-cgu.0.rcgu.o" "main.main.89363361-cgu.1.rcgu.o" "main.main.89363361-cgu.2.rcgu.o" "main.main.89363361-cgu.3.rcgu.o" "main.main.89363361-cgu.4.rcgu.o" "main.main.89363361-cgu.5.rcgu.o" "main.csypsau9u2r8348.rcgu.o" "-Wl,-z,ignore" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-Wl,-Bstatic" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libpanic_unwind-5c87bbe223e6c2a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libobject-d484934062ff9fbb.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libmemchr-e8dbd5835abcbf43.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libaddr2line-909ad09329bde2f9.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libgimli-4d74a3be929697ac.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_demangle-47cbe1d7f7271ae1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd_detect-239fd2d25fb32a00.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libhashbrown-c4a7ce45fb9dec19.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libminiz_oxide-fa6bc3d9bfb4e402.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libadler-419f5a82ddd339a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_alloc-7672b378962c11be.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libunwind-0f9e07f0a032c000.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcfg_if-ede7757c356dfb28.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liblibc-808d56fbc668148a.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liballoc-784767fe059ad3fe.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_core-aa31d7ef0556bbe1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcore-81d07df07db18847.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcompiler_builtins-313a510e63006db2.rlib" "-Wl,-Bdynamic" "-lsocket" "-lposix4" "-lpthread" "-lresolv" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lsendfile" "-llgrp" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-o" "main" "-nodefaultlibs" = note: /opt/cross-solaris/gcc730/lib/gcc/sparcv9-sun-solaris2.10/7.3.0/../../../../sparcv9-sun-solaris2.10/bin/ld: warning: -z ignore ignored. /home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib(std-fa47c8247d587714.std.5c42d2c1-cgu.0.rcgu.o): In function `std::sys::unix::fs::link::h3683dfbfbb4995cb': /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys/unix/fs.rs:1407: undefined reference to `linkat' collect2: error: ld returned 1 exit status = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified = note: use the `-l` flag to specify native libraries to link = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname) ``` linkat() is not available in the system headers of Solaris 10. The hello word example works fine when I build/use rust with this PR change.
@bors r+ |
☀️ Test successful - checks-actions |
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.
Also add a test for rust-lang/rust#110233