about summary refs log tree commit diff
path: root/compiler
AgeCommit message (Collapse)AuthorLines
2023-12-23Introduce `DiagCtxt::treat_next_err_as_bug`.Nicholas Nethercote-7/+8
To fix a FIXME.
2023-12-23Remove unnecessary line breaks from two string literals.Nicholas Nethercote-4/+2
2023-12-23Tweak `flush_delayed`.Nicholas Nethercote-10/+11
- Take a `Vec` instead of an iterator, because that's all that is needed. - Do an early return for the "no bugs" case. - Use `enumerate` and an `i == 0` test to identify the first bug. Those changes mean the `no_bug` variable can be removed, which I found hard to read.
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-454/+250
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the most common diagnostic level. It makes sense to do likewise for the closely-related (and much more widely used) `DiagnosticBuilder` type, letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just `DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many multi-line things becoming single line things.
2023-12-23Use `IntoDiagnostic` default.Nicholas Nethercote-2/+2
`IntoDiagnostic` defaults to `G = ErrorGuaranteed`. Take advantage of this in one place that currently doesn't.
2023-12-23Fix a couple of left-over references to `Handler`.Nicholas Nethercote-2/+2
2023-12-23Improve `use` items in `compiler/rustc_errors/src/lib.rs`.Nicholas Nethercote-30/+27
There are a bunch of them about 400 lines down, which is weird and annoying. This commit moves them up and puts them in a more sensible order.
2023-12-23Streamline `struct_lint_level`.Nicholas Nethercote-104/+13
We can just get the error level in the `match` and then use `DiagnosticBuilder::new`. This then means a number of `DiagCtxt` functions are no longer needed, because this was the one place that used them. Note: the commit changes the treatment of spans for `Expect`, which was different to all the other cases, but this has no apparent effect.
2023-12-23Add comments to `Level`.Nicholas Nethercote-5/+59
There is room for improvement on some of these, but something is better than nothing.
2023-12-22Auto merge of #118824 - aliemjay:perf-region-cons, r=compiler-errorsbors-28/+34
use Vec for region constraints instead of BTreeMap ~1% perf gain Diagnostic regressions need more investigation. r? `@ghost`
2023-12-22Rollup merge of #119215 - mu001999:fix/119209, r=NilstriebMatthias Krüger-1/+4
Emits error if has bound regions Fixes #119209
2023-12-22Rollup merge of #119169 - fmease:pretty-yeet-syntactic-cruft, r=compiler-errorsMatthias Krüger-37/+4
Rid the AST & HIR pretty printer of cruft Found while working on #119163. For `trait Trait: ?Sized {}` (semantically malformed), we currently output `trait Trait for ? Sized {}` (sic!) / `trait Trait for ? Sized { }` (sic!) if `-Zunpretty=expanded` / `-Zunpretty=hir` is passed. `trait Tr for Sized? {}` (#15521) and later also `trait Tr for ?Sized {}` (I guess, #20194) is former Rust syntax. Hence I'm removing these outdated branches. ~~This will conflict with #119163, therefore marking this PR as blocked.~~ Rebased
2023-12-22Rollup merge of #117601 - androm3da:hexagon_unknown_none_elf, r=petrochenkovMatthias Krüger-1/+30
Add support for hexagon-unknown-none-elf as target Still TODO: document usage details for new target
2023-12-22Emits error if has bound regionsr0cky-1/+4
2023-12-22Auto merge of #118847 - eholk:for-await, r=compiler-errorsbors-59/+162
Add support for `for await` loops This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library. Given a loop like: ```rust for await i in iter { ... } ``` this is desugared to something like: ```rust let mut iter = iter.into_async_iter(); while let Some(i) = loop { match core::pin::Pin::new(&mut iter).poll_next(cx) { Poll::Ready(i) => break i, Poll::Pending => yield, } } { ... } ``` This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this. I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue. r? `@compiler-errors`
2023-12-22Rid the AST & HIR pretty printers of syntactic cruftLeón Orell Valerian Liehr-37/+4
2023-12-22Auto merge of #116821 - Nadrieril:fix-opaque-ice, r=compiler-errorsbors-33/+37
Exhaustiveness: reveal opaque types properly Previously, exhaustiveness had no clear policy around opaque types. In this PR I propose the following policy: within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body. I'm not sure how consistent this is with other operations allowed on opaque types; I believe this will require FCP. From what I can tell, this doesn't change anything for non-empty types. The observable changes are: - when the real type is uninhabited, matches within the defining scopes can now rely on that for exhaustiveness, e.g.: ```rust #[derive(Copy, Clone)] enum Void {} fn return_never_rpit(x: Void) -> impl Copy { if false { match return_never_rpit(x) {} } x } ``` - this properly fixes ICEs like https://github.com/rust-lang/rust/issues/117100 that occurred because a same match could have some patterns where the type is revealed and some where it is not. Bonus subtle point: if `x` is opaque, a match like `match x { ("", "") => {} ... }` will constrain its type ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=901d715330eac40339b4016ac566d6c3)). This is not the case for `match x {}`: this will not constain the type, and will only compile if something else constrains the type to be empty. Fixes https://github.com/rust-lang/rust/issues/117100 r? `@oli-obk` Edited for precision of the wording [Included](https://github.com/rust-lang/rust/pull/116821#issuecomment-1813171764) in the FCP on this PR is this rule: > Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
2023-12-22Auto merge of #119173 - compiler-errors:direct-coro-kind, r=TaKO8Kibors-4/+19
Encode `CoroutineKind` directly Probably a quick optimization? r? `@ghost`
2023-12-22Auto merge of #119163 - fmease:refactor-ast-trait-bound-modifiers, ↵bors-163/+166
r=compiler-errors Refactor AST trait bound modifiers Instead of having two types to represent trait bound modifiers in the parser / the AST (`parser::ty::BoundModifiers` & `ast::TraitBoundModifier`), only to map one to the other later, just use `parser::ty::BoundModifiers` (moved & renamed to `ast::TraitBoundModifiers`). The struct type is more extensible and easier to deal with (see [here](https://github.com/rust-lang/rust/pull/119099/files#r1430749981) and [here](https://github.com/rust-lang/rust/pull/119099/files#r1430752116) for context) since it more closely models what it represents: A compound of two kinds of modifiers, constness and polarity. Modeling this as an enum (the now removed `ast::TraitBoundModifier`) meant one had to add a new variant per *combination* of modifier kind, which simply isn't scalable and which lead to a lot of explicit non-DRY matches. NB: `hir::TraitBoundModifier` being an enum is fine since HIR doesn't need to worry representing invalid modifier kind combinations as those get rejected during AST validation thereby immensely cutting down the number of possibilities.
2023-12-22Auto merge of #119097 - nnethercote:fix-EmissionGuarantee, r=compiler-errorsbors-688/+574
Fix `EmissionGuarantee` There are some problems with the `DiagCtxt` API related to `EmissionGuarantee`. This PR fixes them. r? `@compiler-errors`
2023-12-21Add support for hexagon-unknown-none-elf as targetBrian Cain-1/+30
Signed-off-by: Brian Cain <bcain@quicinc.com>
2023-12-21Rollup merge of #119176 - leohowell:fix-apple-watchos-target-name-error, r=lqdMatthias Krüger-1/+1
Fix name error in aarch64_apple_watchos tier 3 target fix llvm_target wrong name `aarch-apple-watchos` to `aarch64-apple-watchos`, sorry for my mistake. previous pr: https://github.com/rust-lang/rust/pull/119074 r? compiler-team
2023-12-21Rollup merge of #119154 - surechen:fix_119067, r=fmeaseMatthias Krüger-8/+9
Simple modification of `non_lifetime_binders`'s diagnostic information to adapt to type binders fixes #119067 Replace diagnostic information "lifetime bounds cannot be used in this context" to "bounds cannot be used in this context". ```rust #![allow(incomplete_features)] #![feature(non_lifetime_binders)] trait Trait {} trait Trait2 where for <T: Trait> ():{} //~^ ERROR bounds cannot be used in this context ```
2023-12-21Fix name error in aarch64_apple_watchos tier 3 targetLeo Howell-1/+1
2023-12-21Auto merge of #119056 - cjgillot:codegen-overalign, r=wesleywiserbors-1/+1
Tolerate overaligned MIR constants for codegen. Fixes https://github.com/rust-lang/rust/issues/117761 cc `@saethlin`
2023-12-21Simple modification of diagnostic informationsurechen-8/+9
fixes #119067
2023-12-21Encode CoroutineKind directlyMichael Goulet-4/+19
2023-12-20Rollup merge of #119168 - petrochenkov:feedvis4, r=compiler-errorsMatthias Krüger-2/+7
resolve: Stop feeding visibilities for import list stems Fixes https://github.com/rust-lang/rust/issues/119126
2023-12-20Rollup merge of #119167 - alef:patch-1, r=compiler-errorsMatthias Krüger-1/+1
E0761: module directory has .rs suffix `rustc --explain E0761` example seems wrong.
2023-12-20Rollup merge of #119145 - aDotInTheVoid:variantdata-struct-struct, ↵Matthias Krüger-28/+37
r=compiler-errors Give `VariantData::Struct` named fields, to clairfy `recovered`. Implements https://github.com/rust-lang/rust/pull/119121#discussion_r1431467066. Supersedes #119121 This way, it's clear what the bool fields means, instead of having to find where it's generated. Changes both ast and hir. r? `@compiler-errors`
2023-12-20Rollup merge of #119141 - celinval:smir-instance-args, r=compiler-errorsMatthias Krüger-0/+15
Add method to get instance instantiation arguments Add a method to get the instance instantiation arguments, and include that information in the instance debug.
2023-12-20Add method to get instance instantiation argumentsCelina G. Val-0/+15
2023-12-20Add `ItemKind::Ctor` to stable mirCelina G. Val-9/+14
2023-12-20Fix crash for `CrateItem::kind()` with constructorsCelina G. Val-5/+8
Change how we classify item kind for DefKind::Ctor
2023-12-20Refactor AST trait bound modifiersLeón Orell Valerian Liehr-163/+166
2023-12-20resolve: Stop feeding visibilities for import list stemsVadim Petrochenkov-2/+7
2023-12-20E0761: module directory has .rs suffixalef-1/+1
2023-12-20Auto merge of #119166 - GuillaumeGomez:rollup-qfgj76w, r=GuillaumeGomezbors-40/+26
Rollup of 3 pull requests Successful merges: - #119115 (Update documentation for `--env` compilation flag) - #119155 (coverage: Check for `async fn` explicitly, without needing a heuristic) - #119159 (Update LLVM submodule) r? `@ghost` `@rustbot` modify labels: rollup
2023-12-20Rollup merge of #119155 - Zalathar:async-fn, r=compiler-errorsGuillaume Gomez-40/+26
coverage: Check for `async fn` explicitly, without needing a heuristic The old code used a heuristic to detect async functions and adjust their coverage spans to produce better output. But there's no need to resort to a heuristic when we can just look back at the original definition and check whether the current function is actually an `async fn`. In addition to being generally nicer, this also gets rid of the one piece of code that specifically cares about `CoverageSpan::is_closure` representing an actual closure. All remaining code that inspects that field just uses it as an indication that the span is a hole that should be carved out of other spans, and then discarded. That opens up the possibility of introducing other kinds of “hole” spans, e.g. for nested functions/types/macros, and having them all behave uniformly. --- `@rustbot` label +A-code-coverage
2023-12-20Auto merge of #119136 - petrochenkov:feedvis3, r=WaffleLapkinbors-22/+23
resolve: Eagerly feed closure visibilities Also factor out all tcx-dependent operations performed for every created definition into `TyCtxt::create_def`. Addresses https://github.com/rust-lang/rust/pull/118657#discussion_r1421424277
2023-12-20Reveal opaque types in exhaustiveness checkingNadrieril-33/+37
2023-12-20Auto merge of #119134 - petrochenkov:feedvis2, r=compiler-errorsbors-2/+8
resolve: Feed visibilities for unresolved trait impl items Fixes https://github.com/rust-lang/rust/issues/119073
2023-12-20resolve: Eagerly feed closure visibilitiesVadim Petrochenkov-22/+23
Also factor out all tcx-dependent operations performed for every created definition into `TyCtxt::create_def`
2023-12-20Auto merge of #119156 - matthiaskrgr:rollup-482ow65, r=matthiaskrgrbors-146/+920
Rollup of 7 pull requests Successful merges: - #118691 (Add check for possible CStr literals in pre-2021) - #118973 (rustc_codegen_ssa: Don't drop `IncorrectCguReuseType` , make `rustc_expected_cgu_reuse` attr work) - #119071 (-Znext-solver: adapt overflow rules to avoid breakage) - #119089 (effects: fix a comment) - #119094 (Add function ABI and type layout to StableMIR) - #119102 (Add arm-none-eabi and armv7r-none-eabi platform-support documentation.) - #119107 (subtype_predicate: remove unnecessary probe) Failed merges: - #119135 (Fix crash due to `CrateItem::kind()` not handling constructors) - #119141 (Add method to get instance instantiation arguments) r? `@ghost` `@rustbot` modify labels: rollup
2023-12-20Rollup merge of #119107 - lcnr:uwuwu, r=compiler-errorsMatthias Krüger-12/+3
subtype_predicate: remove unnecessary probe There is no reason to probe here. The failure either results in an actual type error, in which cases the probe is useless, or it is used inside of evaluate, in which case we're already inside of the `fn evaluation_probe`, so it is also not necessary.
2023-12-20Rollup merge of #119094 - celinval:smir-layout, r=compiler-errorsMatthias Krüger-21/+650
Add function ABI and type layout to StableMIR This change introduces a new module to StableMIR named `abi` with information from `rustc_target::abi` and `rustc_abi`, that allow users to retrieve more low level information required to perform bit-precise analysis. The layout of a type can be retrieved via `Ty::layout`, and the instance ABI can be retrieved via `Instance::fn_abi()`. To properly handle errors while retrieve layout information, we had to implement a few layout related traits. r? ```@compiler-errors```
2023-12-20Rollup merge of #119089 - fmease:dont-ice-on-tilde-const-non-const-trait, ↵Matthias Krüger-1/+1
r=fee1-dead effects: fix a comment r? fee1-dead or compiler
2023-12-20Rollup merge of #119071 - lcnr:overflowo, r=compiler-errorsMatthias Krüger-103/+235
-Znext-solver: adapt overflow rules to avoid breakage Do not erase overflow constraints if they are from equating the impl header when normalizing[^1]. This should be the minimal change to not break crates depending on the old project behavior of "apply impl constraints while only lazily evaluating any nested goals". Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/70, see https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg for the reasoning behind this. Only keeping constraints on overflow for `normalize-to` goals as that's the only thing needed for backcompat. It also allows us to not track the origin of root obligations. The issue with root goals would be something like the following: ```rust trait Foo {} trait Bar {} trait FooBar {} impl<T: Foo + Bar> FooBar for T {} // These two should behave the same, rn we can drop constraints for both, // but if we don't drop `Misc` goals we would only drop the constraints for // `FooBar` unless we track origins of root obligations. fn func1<T: Foo + Bar>() {} fn func2<T: FooBaz>() {} ``` [^1]: mostly, the actual rules are slightly different r? ``@compiler-errors``
2023-12-20Rollup merge of #118973 - Enselic:fix-IncorrectCguReuseType, r=michaelwoeristerMatthias Krüger-2/+2
rustc_codegen_ssa: Don't drop `IncorrectCguReuseType` , make `rustc_expected_cgu_reuse` attr work In [100753], `IncorrectCguReuseType` accidentally stopped being emitted by removing `diag.span_err(...)`. Begin emitting it again rather than just blindly dropping it, and adjust tests accordingly. We assume that there are no bugs and that the currently actual CGU reuse is correct. If there are bugs, they will be discovered and fixed eventually, and the tests will then be updated. [100753]: https://github.com/rust-lang/rust/pull/100753/commits/706452eba74026c51e8d0fa30aee2497c69eafc0#diff-048389738ddcbe0f9765291a29db1fed9a5f03693d4781cfb5aaa97ffb3c7f84 Closes #118972
2023-12-20Rollup merge of #118691 - chfogelman:improve-cstr-error, r=fmeaseMatthias Krüger-7/+29
Add check for possible CStr literals in pre-2021 Fixes [#118654](https://github.com/rust-lang/rust/issues/118654) Adds information to errors caused by possible CStr literals in pre-2021. The lexer separates `c"str"` into two tokens if the edition is less than 2021, which later causes an error when parsing. This error now has a more helpful message that directs them to information about editions. However, the user might also have written `c "str"` in a later edition, so to not confuse people who _are_ using a recent edition, I also added a note about whitespace. We could probably figure out exactly which scenario has been encountered by examining spans and editions, but I figured it would be better not to overcomplicate the creation of the error too much. This is my first code PR and I tried to follow existing conventions as much as possible, but I probably missed something, so let me know!
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-12 23:14:21 +0000