-
Notifications
You must be signed in to change notification settings - Fork 332
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
Automatic Rustup #3879
Merged
Merged
Automatic Rustup #3879
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
Enumerate lint expectations using AttrId This PR implements the idea I outlined in rust-lang/rust#127884 (comment) We can uniquely identify a lint expectation `#[expect(lint0, lint1...)]` using the `AttrId` and the index of the lint inside the attribute. This PR uses this property in `check_expectations`. In addition, this PR stops stashing expected diagnostics to wait for the unstable -> stable `LintExpectationId` mapping: if the lint is emitted with an unstable attribute, it must have been emitted by an `eval_always` query (like inside the resolver), so won't be loaded from cache. Decoding an `AttrId` from the on-disk cache ICEs, so we have no risk of accidentally checking an expectation. Fixes rust-lang/rust#127884 cc `@xFrednet`
generalize: track relevant info in cache key This was previously theoretically incomplete as we could incorrectly generalize as if the type was in an invariant context even though we're in a covariant one. Similar with the `in_alias` flag. r? `@compiler-errors`
Update LLVM to 19 327ca6c Fixes #129887. r? nikic
disallow `naked_asm!` outside of `#[naked]` functions tracking issue: rust-lang/rust#90957 parent PR: rust-lang/rust#128651 I split this out from the parent PR because it's self-contained and because the analysis has to search through all functions and there might be performance regressions. r? `@Amanieu`
interpret: mark some hot functions inline(always) That seems to recover a good part of the perf impact of rust-lang/rust#129778. r? `@saethlin`
update stdarch The goal is mostly to pull in rust-lang/stdarch#1633. r? ```@Amanieu```
enable const-float-classify test, and test_next_up/down on 32bit x86 The test_next_up/down tests have been disabled on all 32bit x86 targets, which goes too far -- they should definitely work on our (tier 1) i686 target, it is only without SSE that we might run into trouble due to rust-lang/rust#114479. However, I cannot reproduce that trouble any more -- maybe that got fixed by rust-lang/rust#123351? The const-float-classify test relied on const traits "because we can", and got disabled when const traits got removed. That's an unfortunate reduction in test coverage of our float functionality, so let's restore the test in a way that does not rely on const traits. The const-float tests are actually testing runtime behavior as well, and I don't think that runtime behavior is covered anywhere else. Probably they shouldn't be called "const-float", but we don't have a `tests/ui/float` folder... should I create one and move them there? Are there any other ui tests that should be moved there? I also removed some FIXME referring to not use x87 for Rust-to-Rust-calls -- that has happened in #123351 so this got fixed indeed. Does that mean we can simplify all that float code again? I am not sure how to test it. Is running the test suite with an i586 target enough? Cc ```@tgross35``` ```@workingjubilee```
Fix linking error when compiling for 32-bit watchOS In rust-lang/rust#124494 (or rust-lang/rust#124748), I mistakenly conflated "not SjLj" to mean "ARM EHABI", which isn't true, 32-bit watchOS uses a third unwinding method called "DWARF CFI". So this PR is effectively a revert of rust-lang/rust#124494, with a few more comments explaining what's going on. Fixes rust-lang/rust#130071. r? Mark-Simulacrum (since you reviewed the original)
Remove needless returns detected by clippy in the compiler
…ChrisDenton maint: update docs for change_time ext and doc links maint: update docs for change_time ext and doc links Related: rust-lang/rust#121478 r? tgross35
notify Miri when intrinsics are changed `@rust-lang/miri` should we notify the entire team, or should I just add myself?
…er-errors miri: fix overflow detection for unsigned pointer offset This is the Miri part of rust-lang/rust#130229. This is already UB in codegen so we better make Miri detect it; updating the docs may take time if we have to follow some approval process, but let's make Miri match reality ASAP. r? ``@scottmcm``
…ieyouxu Use the same span for attributes and Try expansion of ? This is needed for Clippy to know that the `#[allow(unused)]` attributes added by the expansion of `?` are part of the desugaring, and that they do not come from the user code. rust-lang/rust-clippy#13380 exhibits a manifestation of this problem and will be fixed by this change.
Limit `libc::link` usage to `nto70` target only, not NTO OS It seems QNX 7.0 does not support `linkat` at all (most tests were failing). Limiting to QNX 7.0 only, while using `linkat` for the future versions seems like the right path forward (tested on 7.0). Fixes #129895 CC: `@japaric` `@flba-eb` `@saethlin`
Rollup of 10 pull requests Successful merges: - #129103 (Don't warn empty branches unreachable for now) - #129696 (update stdarch) - #129835 (enable const-float-classify test, and test_next_up/down on 32bit x86) - #130077 (Fix linking error when compiling for 32-bit watchOS) - #130114 (Remove needless returns detected by clippy in the compiler) - #130168 (maint: update docs for change_time ext and doc links) - #130228 (notify Miri when intrinsics are changed) - #130239 (miri: fix overflow detection for unsigned pointer offset) - #130244 (Use the same span for attributes and Try expansion of ?) - #130248 (Limit `libc::link` usage to `nto70` target only, not NTO OS) r? `@ghost` `@rustbot` modify labels: rollup
Bump Unicode to version 16.0.0 [Unicode 16.0.0 is out!](https://www.unicode.org/versions/Unicode16.0.0/) This PR updates Unicode data embedded in `core`.
@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.
No description provided.