about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2024-12-14Don't make a def id for impl_trait_in_bindingsMichael Goulet-0/+20
2024-12-14Auto merge of #134296 - matthiaskrgr:rollup-o0sxozj, r=matthiaskrgrbors-249/+327
Rollup of 6 pull requests Successful merges: - #132150 (Fix powerpc64 big-endian FreeBSD ABI) - #133942 (Clarify how to use `black_box()`) - #134081 (Try to evaluate constants in legacy mangling) - #134192 (Remove `Lexer`'s dependency on `Parser`.) - #134208 (coverage: Tidy up creation of covmap and covfun records) - #134211 (On Neutrino QNX, reduce the need to set archiver via environment variables) r? `@ghost` `@rustbot` modify labels: rollup
2024-12-14Auto merge of #134185 - compiler-errors:impl-trait-in-bindings, r=oli-obkbors-52/+442
(Re-)Implement `impl_trait_in_bindings` This reimplements the `impl_trait_in_bindings` feature for local bindings. "`impl Trait` in bindings" serve as a form of *trait* ascription, where the type basically functions as an infer var but additionally registering the `impl Trait`'s trait bounds for the infer type. These trait bounds can be used to enforce that predicates hold, and can guide inference (e.g. for closure signature inference): ```rust let _: impl Fn(&u8) -> &u8 = |x| x; ``` They are implemented as an additional set of bounds that are registered when the type is lowered during typeck, and then these bounds are tied to a given `CanonicalUserTypeAscription` for borrowck. We enforce these `CanonicalUserTypeAscription` bounds during borrowck to make sure that the `impl Trait` types are sensitive to lifetimes: ```rust trait Static: 'static {} impl<T> Static for T where T: 'static {} let local = 1; let x: impl Static = &local; //~^ ERROR `local` does not live long enough ``` r? oli-obk cc #63065 --- Why can't we just use TAIT inference or something? Well, TAITs in bodies have the problem that they cannot reference lifetimes local to a body. For example: ```rust type TAIT = impl Display; let local = 0; let x: TAIT = &local; //~^ ERROR `local` does not live long enough ``` That's because TAITs requires us to do *opaque type inference* which is pretty strict, since we need to remap all of the lifetimes of the hidden type to universal regions. This is simply not possible here. --- I consider this part of the "impl trait everywhere" experiment. I'm not certain if this needs yet another lang team experiment.
2024-12-14Auto merge of #134294 - matthiaskrgr:rollup-anh6io8, r=matthiaskrgrbors-54/+157
Rollup of 8 pull requests Successful merges: - #134252 (Fix `Path::is_absolute` on Hermit) - #134254 (Fix building `std` for Hermit after `c_char` change) - #134255 (Update includes in `/library/core/src/error.rs`.) - #134261 (Document the symbol Visibility enum) - #134262 (Arbitrary self types v2: adjust diagnostic.) - #134265 (Rename `ty_def_id` so people will stop using it by accident) - #134271 (Arbitrary self types v2: better feature gate test) - #134274 (Add check-pass test for `&raw`) r? `@ghost` `@rustbot` modify labels: rollup
2024-12-14Rollup merge of #134211 - flba-eb:add_qnx_archiver, r=compiler-errorsMatthias Krüger-0/+10
On Neutrino QNX, reduce the need to set archiver via environment variables This adds support for automatically selecting the correct `ar` tool when compiling for Neutrino QNX. Once https://github.com/rust-lang/cc-rs/pull/1319 is merged and a new cc version is integrated, all environment variables of the [Neutrino documentation](https://github.com/rust-lang/rust/blob/stable/src/doc/rustc/src/platform-support/nto-qnx.md) can be removed. CC: ````````@jonathanpallant```````` ````````@japaric```````` ````````@gh-tr```````` ````````@AkhilTThomas````````
2024-12-14Rollup merge of #134208 - Zalathar:covmap-covfun, r=compiler-errorsMatthias Krüger-65/+61
coverage: Tidy up creation of covmap and covfun records This is a small follow-up to #134163 that mostly just inlines and renames some variables, and adds a few comments. It also slightly defers the creation of the LLVM value that holds the filename table, to just before the value is needed. --- try-job: x86_64-mingw-2 try-job: dist-x86_64-linux
2024-12-14Rollup merge of #134192 - nnethercote:rm-Lexer-Parser-dep, r=compiler-errorsMatthias Krüger-174/+68
Remove `Lexer`'s dependency on `Parser`. Lexing precedes parsing, as you'd expect: `Lexer` creates a `TokenStream` and `Parser` then parses that `TokenStream`. But, in a horrendous violation of layering abstractions and common sense, `Lexer` depends on `Parser`! The `Lexer::unclosed_delim_err` method does some error recovery that relies on creating a `Parser` to do some post-processing of the `TokenStream` that the `Lexer` just created. This commit just removes `unclosed_delim_err`. This change removes `Lexer`'s dependency on `Parser`, and also means that `lex_token_tree`'s return value can have a more typical form. The cost is slightly worse error messages in two obscure cases, as shown in these tests: - tests/ui/parser/brace-in-let-chain.rs: there is slightly less explanation in this case involving an extra `{`. - tests/ui/parser/diff-markers/unclosed-delims{,-in-macro}.rs: the diff marker detection is no longer supported (because that detection is implemented in the parser). In my opinion this cost is outweighed by the magnitude of the code cleanup. r? ```````@chenyukang```````
2024-12-14Rollup merge of #134081 - oli-obk:push-prpsqxxynxnq, r=BoxyUwUMatthias Krüger-4/+96
Try to evaluate constants in legacy mangling Best reviewed commit by commit. It seems kind of odd to treat literals differently from unevaluated free constants. So let's evaluate those constants and only fall back to `_` rendering if that fails to result in an integral constant
2024-12-14Rollup merge of #133942 - BD103:black-box-docs, r=saethlinMatthias Krüger-3/+89
Clarify how to use `black_box()` Closes #133923. r? libs ^ (I think that's the right group, this is my first time!) This PR adds further clarification on the [`black_box()`](https://doc.rust-lang.org/stable/std/hint/fn.black_box.html) documentation. Specifically, it teaches _how_ to use it, instead of just _when_ to use it. I tried my best to make it clear and accurate, but a lot of my information is sourced from https://github.com/rust-lang/rust-clippy/issues/12707 and [manually inspecting assembly](https://godbolt.org/). Please tell me if I got anything wrong!
2024-12-14Rollup merge of #132150 - taiki-e:ppc64-freebsd-abi, r=pnkfelixMatthias Krüger-3/+3
Fix powerpc64 big-endian FreeBSD ABI Note that FreeBSD version bump may be reverted due to https://github.com/rust-lang/rust/pull/120869#issuecomment-2438685835. We may want to wait to merge this until that discussion is complete. Fixes https://github.com/rust-lang/rust/pull/120869#discussion_r1813233054 > > PPC64 FreeBSD (ELFv1 and ELFv2, version 13.2) > > It seems odd that ELFv1 and 13.N coexist. > > https://www.freebsd.org/releases/13.0R/relnotes/ > > > powerpc64 switched to ELFv2 ABI at the same time it switched to LLVM. This brings us to a parity with modern Linux distributions. This also makes the binaries from previous FreeBSD versions incompatible with 13.0-RELEASE. Kernel still supports ELFv1, so jails and chroots using older FreeBSD versions are still compatible. [e4399d169acc](https://cgit.freebsd.org/src/commit/?id=e4399d169acc) > > Well, it is also odd that this target claims ELFv2 support since our ABI code does not use ELFv2 on this target. > > https://github.com/rust-lang/rust/blob/be01dabfefd2daa4574b974f571c7852085d60cb/compiler/rustc_target/src/callconv/powerpc64.rs#L102-L111 ````````@rustbot```````` label +O-PowerPC +O-freebsd
2024-12-14Auto merge of #134292 - matthiaskrgr:rollup-3kbjocl, r=matthiaskrgrbors-957/+568
Rollup of 8 pull requests Successful merges: - #134181 (Tweak multispan rendering to reduce output length) - #134209 (validate `--skip` and `--exclude` paths) - #134231 (rustdoc-search: fix mismatched path when parent re-exported twice) - #134236 (crashes: more tests v2) - #134240 (Only dist `llvm-objcopy` if llvm tools are enabled) - #134244 (rustc_borrowck: Stop suggesting the invalid syntax `&mut raw const`) - #134251 (A bunch of cleanups (part 2)) - #134256 (Use a more precise span in placeholder_type_error_diag) r? `@ghost` `@rustbot` modify labels: rollup
2024-12-14(Re-)Implement impl_trait_in_bindingsMichael Goulet-25/+391
2024-12-14Split UserTypeAnnotation to have a kindMichael Goulet-36/+60
2024-12-14Rollup merge of #134274 - fmease:amp-raw-is-a-normal-borrow, r=NoratriebMatthias Krüger-0/+30
Add check-pass test for `&raw` `&raw` denotes a normal/non-raw borrow of the path `raw`, not the start of raw borrow since it's not followed by either `const` or `mut`. Ensure this (and variants) will never regress! When I saw the open diagnostic issue https://github.com/rust-lang/rust/issues/133231 (better parse error (recovery) on `&raw <expr>`), it made me think that we have to make sure that we will never commit too early/overzealously(†) when encountering the sequence `&raw`, even during parse error recovery! Modifying the parser to eagerly treat `&raw` as the start of a raw borrow expr only lead to a single UI test failing, namely [tests/ui/enum-discriminant/ptr_niche.rs](https://github.com/rust-lang/rust/blob/4847d6a9d07d4be9ba3196f6ad444af2d7bdde72/tests/ui/enum-discriminant/ptr_niche.rs). However, this is just coincidental — it didn't *intentionally* test this edge case of the grammar. --- †: With "eager" I mean something like: ```patch diff --git a/compiler/rustc_parse/src/parser/expr.rs b/compiler/rustc_parse/src/parser/expr.rs index 0904a42d8a4..68d690fd602 100644 --- a/compiler/rustc_parse/src/parser/expr.rs +++ b/compiler/rustc_parse/src/parser/expr.rs `@@` -873,11 +873,16 `@@` fn error_remove_borrow_lifetime(&self, span: Span, lt_span: Span) { /// Parse `mut?` or `raw [ const | mut ]`. fn parse_borrow_modifiers(&mut self) -> (ast::BorrowKind, ast::Mutability) { - if self.check_keyword(kw::Raw) && self.look_ahead(1, Token::is_mutability) { + if self.eat_keyword(kw::Raw) { // `raw [ const | mut ]`. - let found_raw = self.eat_keyword(kw::Raw); - assert!(found_raw); - let mutability = self.parse_const_or_mut().unwrap(); + let mutability = self.parse_const_or_mut().unwrap_or_else(|| { + let span = self.prev_token.span; + self.dcx().emit_err(ExpectedMutOrConstInRawBorrowExpr { + span, + after_ampersand: span.shrink_to_hi(), + }); + ast::Mutability::Not + }); (ast::BorrowKind::Raw, mutability) } else { // `mut?` ``` --- r? compiler
2024-12-14Rollup merge of #134271 - adetaylor:feature-gate-test, r=wesleywiserMatthias Krüger-3/+42
Arbitrary self types v2: better feature gate test Slight improvement to the test for the `arbitrary_self_types_pointers` feature gate, to ensure it's independent of the `arbitrary_self_types` gate. Part of #44874 r? `@wesleywiser`
2024-12-14Rollup merge of #134265 - compiler-errors:ty_def_id, r=oli-obkMatthias Krüger-19/+17
Rename `ty_def_id` so people will stop using it by accident This function is just for cycle detection, but people keep using it because they think it's the right way of getting the def id from a `Ty` (and I can't blame them necessarily).
2024-12-14Rollup merge of #134262 - adetaylor:revert-diagnostics, r=compiler-errorsMatthias Krüger-23/+45
Arbitrary self types v2: adjust diagnostic. The recently landed PR #132961 to adjust arbitrary self types was a bit overenthusiastic, advising folks to use the new Receiver trait even before it's been stabilized. Revert to the older wording of the lint in such cases. Tracking issue #44874 r? ``@wesleywiser``
2024-12-14Rollup merge of #134261 - bjorn3:document_symbol_visibility, r=lqdMatthias Krüger-0/+12
Document the symbol Visibility enum
2024-12-14Rollup merge of #134255 - bjoernager:master, r=NoratriebMatthias Krüger-2/+2
Update includes in `/library/core/src/error.rs`. This PR removes the `crate::fmt::Result` include in `/library/core/src/error.rs`. The main issue with this `use` statement is that it shadows the `Result` type from the prelude (i.e. `crate::result::Result`). This indirectly makes all docs references to `Result` in this module point to the wrong type (but only in `core::error` - not `std::error`, wherein this include isn't present to begin with). Fixes: #134169
2024-12-14Rollup merge of #134254 - hermit-os:hermit-c_char, r=workingjubileeMatthias Krüger-6/+6
Fix building `std` for Hermit after `c_char` change These changes were made necessary by https://github.com/rust-lang/rust/pull/132975.
2024-12-14Rollup merge of #134252 - hermit-os:hermit-is_absolute, r=tgross35Matthias Krüger-1/+3
Fix `Path::is_absolute` on Hermit Paths on Hermit work like paths on Unix. Closes https://github.com/rust-lang/rust/issues/132141.
2024-12-14Rollup merge of #134256 - krtab:suggestion_overlapping, r=petrochenkovMatthias Krüger-8/+64
Use a more precise span in placeholder_type_error_diag Closes: https://github.com/rust-lang/rust/issues/123861
2024-12-14Rollup merge of #134251 - bjorn3:various_cleanups2, r=oli-obkMatthias Krüger-71/+43
A bunch of cleanups (part 2) Just like https://github.com/rust-lang/rust/pull/133567 these were all found while looking at the respective code, but are not blocking any other changes I want to make in the short term.
2024-12-14Rollup merge of #134244 - Enselic:no-mut-hint-for-raw-ref, r=jieyouxuMatthias Krüger-16/+70
rustc_borrowck: Stop suggesting the invalid syntax `&mut raw const` A legitimate suggestion would be to change from &raw const val to &raw mut val But until we have figured out how to make that happen we should at least stop suggesting invalid syntax. I recommend review commit-by-commit. Part of #127562
2024-12-14Rollup merge of #134240 - cuviper:dist-llvm-tools, r=jieyouxuMatthias Krüger-1/+1
Only dist `llvm-objcopy` if llvm tools are enabled This uses the same condition that #132720 added in the compilation phase. r? ``@jieyouxu``
2024-12-14Rollup merge of #134236 - matthiaskrgr:tests12122024, r=compiler-errorsMatthias Krüger-0/+122
crashes: more tests v2 try-job: aarch64-apple try-job: x86_64-msvc try-job: x86_64-gnu
2024-12-14Rollup merge of #134231 - notriddle:notriddle/mismatched-path, r=GuillaumeGomezMatthias Krüger-1/+27
rustdoc-search: fix mismatched path when parent re-exported twice
2024-12-14Rollup merge of #134209 - onur-ozkan:check-skip-paths, r=jieyouxuMatthias Krüger-1/+25
validate `--skip` and `--exclude` paths Fixes #134198 cc ``@ChrisDenton``
2024-12-14Rollup merge of #134181 - estebank:trim-render, r=oli-obkMatthias Krüger-859/+216
Tweak multispan rendering to reduce output length Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments. We do that check not only on the first 4 lines of the multispan, but now also on the previous to last line as well.
2024-12-13Auto merge of #134269 - matthiaskrgr:rollup-fkshwux, r=matthiaskrgrbors-635/+1337
Rollup of 7 pull requests Successful merges: - #133900 (Advent of `tests/ui` (misc cleanups and improvements) [1/N]) - #133937 (Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them) - #133938 (`rustc_mir_dataflow` cleanups, including some renamings) - #134058 (interpret: reduce usage of TypingEnv::fully_monomorphized) - #134130 (Stop using driver queries in the public API) - #134140 (Add AST support for unsafe binders) - #134229 (Fix typos in docs on provenance) r? `@ghost` `@rustbot` modify labels: rollup
2024-12-13Auto merge of #133099 - RalfJung:forbidden-hardfloat-features, r=workingjubileebors-409/+611
forbid toggling x87 and fpregs on hard-float targets Part of https://github.com/rust-lang/rust/issues/116344, follow-up to https://github.com/rust-lang/rust/pull/129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](https://github.com/rust-lang/rust/issues/130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes https://github.com/rust-lang/rust/issues/132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
2024-12-13Document the symbol Visibility enumbjorn3-0/+12
2024-12-13Account for `///` when rendering multiline spansEsteban Küber-43/+144
Don't consider `///` and `//!` docstrings to be empty for the purposes of multiline span rendering.
2024-12-13Fix miri testsEsteban Küber-12/+1
2024-12-13Add check-pass test for `&raw`León Orell Valerian Liehr-0/+30
2024-12-13Arbitrary self types v2: better feature gate testAdrian Taylor-3/+42
Slight improvement to the test for the arbitrary_self_types_pointers feature gate, to ensure it's independent of the arbitrary_self_types gate. Part of #44874
2024-12-13Rename ty_def_id so people will stop using it by accidentMichael Goulet-19/+17
2024-12-13Rollup merge of #134229 - purplesyringa:provenance-docs, r=saethlinMatthias Krüger-4/+5
Fix typos in docs on provenance This is related to [strict provenance](https://github.com/rust-lang/rust/issues/95228). Added a couple cross-refs, also replaced > Create a pointer without provenance from just an address (see [`ptr::dangling`]). with > Create a pointer without provenance from just an address (see [`without_provenance`]). as this method actually takes an address.
2024-12-13Rollup merge of #134140 - compiler-errors:unsafe-binders-ast, r=oli-obkMatthias Krüger-18/+616
Add AST support for unsafe binders I'm splitting up #130514 into pieces. It's impossible for me to keep up with a huge PR like that. I'll land type system support for this next, probably w/o MIR lowering, which will come later. r? `@oli-obk` cc `@BoxyUwU` and `@lcnr` who also may want to look at this, though this PR doesn't do too much yet
2024-12-13Rollup merge of #134130 - bjorn3:prepare_driver_query_removal, r=oli-obkMatthias Krüger-34/+32
Stop using driver queries in the public API Follow up to https://github.com/rust-lang/rust/pull/132410 and https://github.com/rust-lang/rust/pull/133567 The next PR will completely get rid of driver queries. That PR will also contains some non-trivial refactorings enabled by no longer needing to support entering TyCtxt multiple times after it is constructed. The changes in the current PR have been split out to make it easier to review the api changes and to reduce the size of the next PR to review. ## Custom driver breaking change The `after_crate_root_parsing` and `after_expansion` callbacks now accept `ast::Crate` and `TyCtxt` respectively rather than `Queries`. The only safe query in `Queries` to call inside these callbacks are `parse()` and `global_ctxt()` respectively which allows you to access the `ast::Crate` and `TyCtxt` either way. To fix your custom driver, replace the `queries: &'tcx Queries<'tcx>` argument with `crate_: ast::Crate` and `tcx: TyCtxt<'tcx>` respectively and for `after_expansion` remove your `queries.global_ctxt().unwrap().enter(|tcx| { ... })` call and only keep the contents of the closure.
2024-12-13Rollup merge of #134058 - RalfJung:interpret-typing-env, r=lcnrMatthias Krüger-8/+9
interpret: reduce usage of TypingEnv::fully_monomorphized r? `@lcnr`
2024-12-13Rollup merge of #133938 - nnethercote:rustc_mir_dataflow-renamings, r=oli-obkMatthias Krüger-422/+360
`rustc_mir_dataflow` cleanups, including some renamings Some opinionated commits in this collection, let's see how we go. r? `@cjgillot`
2024-12-13Rollup merge of #133937 - ↵Matthias Krüger-85/+178
estebank:silence-resolve-errors-from-mod-with-parse-errors, r=davidtwco Keep track of parse errors in `mod`s and don't emit resolve errors for paths involving them When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around in the HIR and mark its `DefId` in the `Resolver`. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for. When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by expansion of `mod`s with parse errors. Fix https://github.com/rust-lang/rust/issues/97734.
2024-12-13Rollup merge of #133900 - jieyouxu:ui-cleanup-1, r=fmeaseMatthias Krüger-64/+137
Advent of `tests/ui` (misc cleanups and improvements) [1/N] Part of #133895. Misc improvements to some ui tests immediately under `tests/ui/`. Best reviewed commit-by-commit. Thanks `@clubby789` for PR title suggestion 😸. r? compiler
2024-12-13Auto merge of #134122 - oli-obk:push-zqnyznxtpnll, r=petrochenkovbors-44/+99
Move impl constness into impl trait header This PR is kind of the opposite of the rejected https://github.com/rust-lang/rust/pull/134114 Instead of moving more things into the `constness` query, we want to keep them where their corresponding hir nodes are lowered. So I gave this a spin for impls, which have an obvious place to be (the impl trait header). And surprisingly it's also a perf improvement (likely just slightly better query & cache usage). The issue was that removing anything from the `constness` query makes it just return `NotConst`, which is wrong. So I had to change it to `bug!` out if used wrongly, and only then remove the impl blocks from the `constness` query. I think this change is good in general, because it makes using `constness` more robust (as can be seen by how few sites that had to be changed, so it was almost solely used specifically for the purpose of asking for functions' constness). The main thing where this change was not great was in clippy, which was using the `constness` query as a general DefId -> constness map. I added a `DefKind` filter in front of that. If it becomes a more common pattern we can always move that helper into rustc.
2024-12-13rustdoc-search: update test with now-shorter function pathMichael Howell-1/+1
Both paths are correct. This one's better.
2024-12-13Arbitrary self types v2: adjust diagnostic.Adrian Taylor-23/+45
The recently landed PR to adjust arbitrary self types was a bit overenthusiastic, advising folks to use the new Receiver trait even before it's been stabilized. Revert to the older wording of the lint in such cases.
2024-12-13rustc_borrowck: Convert suggest_ampmut() 4-tuple to struct for readabilityMartin Nordholts-13/+46
2024-12-13rustc_borrowck: Stop suggesting the invalid syntax `&mut raw const`Martin Nordholts-5/+5
A legitimate suggestion would be to change from &raw const val to &raw mut val But until we have figured out how to make that happen we should at least stop suggesting invalid syntax.
2024-12-13Add regression test for issue 127562Martin Nordholts-0/+22
The test fails in this commit. The next commit fixes it.