-
Notifications
You must be signed in to change notification settings - Fork 356
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 #4144
Closed
Closed
Automatic Rustup #4144
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
minor: Sync from downstream
minor: Break out of waiting for debugger on Windows using native debugger check API.
Back out "internal: Disable rustc test metrics"
Rename `rust-analyzer.statusBar.documentSelector` to `showStatusBar`, add "always" and "never" options.
…ator internal: Standardize how we take iterator parameters in `SyntaxFactory`
feat: Show substitution where hovering over generic things
feat: Unify handling of path diagnostics in hir-ty
Treat ; as a terminator rather part of a glued expression
minor: Sync from downstream
internal: Migrate `if let` replacement assists to `SyntaxEditor`
fix: Fix `env`/`option_env` macro check disregarding macro_rules definitions
fix: Make edition per-token, not per-file
feat: Add a new and improved syntax tree view
…braheemdev Improve `select_nth_unstable` documentation clarity * Instead uses `before` and `after` variable names in the example where `greater` and `lesser` are flipped. * Uses `<=` and `>=` instead of "less than or equal to" and "greater than or equal to" to make the docs more concise. * General attempt to remove unnecessary words and be more precise. For example it seems slightly wrong to say "its final sorted position", since this implies there is only one sorted position for this element.
Miri subtree update r? `@ghost`
minor: Sync from downstream
…tability proc-macro-srv: make usage of RTLD_DEEPBIND portable
fix: Fix a bug where enum variants were not considered properly in type ns resolution
…kground-thread lsp-server: Drop outgoing messages on background thread
Extract variable assist triggers less eagerly
feat: Add the ability to jump from `into` to `from` definitions
…acy extern "rust-intrinsic" blocks
When LLVM's location discriminator value limit is exceeded, emit locations with dummy spans instead of dropping them entirely Dropping them fails `-Zverify-llvm-ir`. Fixes #135332. r? `@jieyouxu`
Reexport likely/unlikely in std::hint Since `likely`/`unlikely` should be working now, we could reexport them in `std::hint`. I'm not sure if this is already approved or if it requires approval Tracking issue: #26179
… r=lqd Respect --sysroot for rustc -vV and -Cpasses=list This is necessary when the specified codegen backend is in a custom sysroot. Fixes rust-lang/rust#135165
Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase Part of #132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro - Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro. - Skipped `.md` files and test files to avoid unnecessary changes.
Recognise new IPv6 documentation range from IETF RFC 9637 This PR adds the `3fff::/20` range defined by [IETF RFC 9637](https://datatracker.ietf.org/doc/rfc9637/) to those ranges which `Ipv6Addr::is_documentation` recognises as a documentation IP. See also: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml Unstable tracking issue: #27709
…Kobzol Update contributing docs for submodule/subtree changes Noticed in rust-lang/rust#135337 (comment). r? ``@Kobzol`` (or anyone really)
Subtree update of `rust-analyzer` r? ``@ghost``
Subtree sync for rustc_codegen_cranelift Nothing too exciting this time, but this includes a fix for a linker hang on Windows: rust-lang/rustc_codegen_cranelift#1554 r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler
Rollup of 7 pull requests Successful merges: - #133695 (Reexport likely/unlikely in std::hint) - #135330 (Respect --sysroot for rustc -vV and -Cpasses=list) - #135333 (Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase) - #135741 (Recognise new IPv6 documentation range from IETF RFC 9637) - #135770 (Update contributing docs for submodule/subtree changes) - #135775 (Subtree update of `rust-analyzer`) - #135776 (Subtree sync for rustc_codegen_cranelift) r? `@ghost` `@rustbot` modify labels: rollup
Enable `unreachable_pub` lint in core This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) as warn in `core`, `rtstartup` and `panic_unwind`. The motivation is similar to the compiler [MCP: Enable deny(unreachable_pub) on `rustc_*` crates](rust-lang/compiler-team#773 (comment)) : > "Where is this thing used?" is a question I ask all the time when reading unfamiliar code. Because of this, I generally find it annoying when things are marked with a more permissive visibility than necessary. "This thing marked pub, which other crates is it used in? Oh, it's not used in any other crates." Another motivation is to help to lint by utilizing it in-tree and seeing it's limitation in more complex scenarios. The diff was mostly generated with `./x.py fix --stage 1 library/core/ -- --broken-code`, as well as manual edits for code in macros, generated code and other targets. r? libs
Outline panicking code for `LocalKey::with` See rust-lang/rust#115491 for prior related modifications. https://godbolt.org/z/MTsz87jGj shows a reduction of the code size for TLS accesses.
CI: split x86_64-msvc job using windows 2025 try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: dist-x86_64-msvc
Rework dyn trait lowering to stop being so intertwined with trait alias expansion This PR reworks the trait object lowering code to stop handling trait aliases so funky, and removes the `TraitAliasExpander` in favor of a much simpler design. This refactoring is important for making the code that I'm writing in rust-lang/rust#133397 understandable and easy to maintain, so the diagnostics regressions are IMO inevitable. In the old trait object lowering code, we used to be a bit sloppy with the lists of traits in their unexpanded and expanded forms. This PR largely rewrites this logic to expand the trait aliases *once* and handle them more responsibly throughout afterwards. Please review this with whitespace disabled. r? lcnr
remove support for the (unstable) #[start] attribute As explained by `@Noratrieb:` `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction. I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple: - `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail) - `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways* `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place. Note that this feature has **not** been RFCed in the first place. *This comment was posted [in May](rust-lang/rust#29633 (comment)) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.* Closes rust-lang/rust#29633 try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
bump compiler and tools to windows 0.59, bootstrap to 0.57 This bumps compiler and tools to windows 0.59 (temporary dupes version, as `sysinfo` still depend on <= 0.57). Bootstrap bumps only to 0.57 (the same sysinfo dep). This additionally resolves my comment rust-lang/rust#130874 (comment) Will work on it in follow up pr: There still some sus imports for `rustc_driver.dll` like ws2_32 or RoOriginateErrorW, but i will look at them later.
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.
Please close and re-open this PR to trigger CI, then enable auto-merge.