about summary refs log tree commit diff
path: root/compiler
AgeCommit message (Collapse)AuthorLines
2023-09-22Auto merge of #116001 - fmease:validate-crate-name-extern-cli-opt, r=est31bors-0/+31
[breaking change] Validate crate name in `--extern` [MCP 650] Reject non-ASCII-identifier crate names passed to the CLI option `--extern` (`rustc`, `rustdoc`). Implements [MCP 650](https://github.com/rust-lang/compiler-team/issues/650) (except that we only allow ASCII identifiers not arbitrary Rust identifiers). Fixes #113035. [As mentioned on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Disallow.20non-identifier-valid.20--extern.20cr.E2.80.A6.20compiler-team.23650/near/376826988), doing a crater run probably doesn't make sense since it wouldn't yield anything. Most users don't interact with `rustc` directly but only ever through Cargo which always passes a valid crate name to `--extern` when it invokes `rustc` and `rustdoc`. In any case, the user wouldn't be able to use such a crate name in the source code anyway. Note that I'm not using [`rustc_session::output::validate_crate_name`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/output/fn.validate_crate_name.html) (used for `--crate-name` and `#![crate_name]`) since the latter doesn't reject non-ASCII crate names and ones that start with a digit. As an aside, I've also thought about getting rid of `validate_crate_name` entirely in a separate PR (with another MCP) in favor of `is_ascii_ident` to reject more weird `--crate-name`s, `#![crate_name]`s and file names but I think that would lead to a lot of actual breakage, namely because of file names starting with a digit. In `tests/ui` 9 tests would be impacted for example. CC `@estebank` r? `@est31`
2023-09-22Auto merge of #115696 - RalfJung:closure-ty-print, r=oli-obkbors-12/+12
adjust how closure/generator types are printed I saw `&[closure@$DIR/issue-20862.rs:2:5]` and I thought it is a slice type, because that's usually what `&[_]` is... it took me a while to realize that this is just a confusing printer and actually there's no slice. Let's use something that cannot be mistaken for a regular type.
2023-09-22Auto merge of #115690 - ShE3py:Z-treat-err-as-bug, r=petrochenkovbors-14/+19
Allow `-Z treat-err-as-bug=0` Makes `-Z treat-err-as-bug=0` behave as if the option wasn't present instead of asking the value to be ⩾ 1. This enables a quick on/off of the option, as you only need to change one character instead of removing the whole `-Z`. Also update some text, e.g. ```bash $ rustc -Z help | grep treat-err-as-bug -Z treat-err-as-bug=val -- treat error number `val` that occurs as bug ``` where the value could be interpreted as an error code instead of an ordinal.
2023-09-22Allow `-Z treat-err-as-bug=0`Lieselotte-14/+19
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
2023-09-22Rollup merge of #116049 - RalfJung:future-incompat, r=NilstriebMatthias Krüger-30/+77
give FutureIncompatibilityReason variants more explicit names Also make the `reason` field mandatory when declaring a lint, to make sure this is a deliberate decision.
2023-09-22Rollup merge of #116041 - compiler-errors:rigid-note, r=RalfJungMatthias Krüger-0/+5
Add note to `is_known_rigid` Adds a note requested by `@RalfJung` in https://github.com/rust-lang/rust/pull/114941#discussion_r1329963704 Let me know if there are any other fns that need documentation, I could throw them into this PR too :)
2023-09-22Rollup merge of #116039 - estebank:nested-tait, r=compiler-errorsMatthias Krüger-2/+7
Account for nested `impl Trait` in TAIT Fix #116031. r? `@compiler-errors`
2023-09-22Auto merge of #114776 - fee1-dead-contrib:enable-effects-in-libcore, r=oli-obkbors-8/+31
Enable effects for libcore ~~r? `@oli-obk~~` forgot you are on vacation, oops
2023-09-22make the reason: field mandatory for @future_incompatible lintsRalf Jung-19/+51
2023-09-22give FutureIncompatibilityReason variants more explicit namesRalf Jung-19/+34
2023-09-22Auto merge of #115910 - eduardosm:lang-fns-target-features, r=cjgillotbors-3/+43
Prevent using `#[target_feature]` on lang item functions Fixes https://github.com/rust-lang/rust/issues/109411 and also prevents from using `#[target_feature]` on other `fn` lang items to mitigate the concerns from https://github.com/rust-lang/rust/issues/109411#issuecomment-1477030273.
2023-09-22Add note to is_known_rigidMichael Goulet-0/+5
2023-09-22Auto merge of #115920 - Zoxc:depkind-u16, r=cjgillotbors-518/+508
Move `DepKind` to `rustc_query_system` and define it as `u16` This moves the `DepKind` type to `rustc_query_system` where it's defined with an inner `u16` field. This decouples it from `rustc_middle` and is a step towards letting other crates define dep kinds. It also allows some type parameters to be removed. The `DepKind` trait is replaced with a `Deps` trait. That's used when some operations or information about dep kinds which is unavailable in `rustc_query_system` are still needed. r? `@cjgillot`
2023-09-21Auto merge of #115897 - eduardosm:check-fn-sig, r=compiler-errorsbors-268/+229
rustc_hir_analysis: add a helper to check function the signature mismatches This function is now used to check `#[panic_handler]`, `start` lang item, `main`, `#[start]` and intrinsic functions. The diagnosis produced are now closer to the ones produced by trait/impl method signature mismatch. This is the first time I do anything with rustc_hir_analysis/rustc_hir_typeck, so comments and suggestions about things I did wrong or that could be improved will be appreciated.
2023-09-21Auto merge of #115864 - compiler-errors:rpitit-sugg, r=estebankbors-29/+185
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound First commit allows us to store the span of the `async` keyword in HIR. Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in #115822. This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
2023-09-21adjust how closure/generator types and rvalues are printedRalf Jung-12/+12
2023-09-21Auto merge of #115230 - Vtewari2311:mod-hurd-latest, r=b-naberbors-4/+63
added support for GNU/Hurd adding support for i686-unknown-hurd-gnu
2023-09-21Suggest desugaring to RPITIT when AFIT is required to be an auto traitMichael Goulet-0/+137
2023-09-21Record asyncness span in HIRMichael Goulet-29/+48
2023-09-21Account for nested `impl Trait` in TAITEsteban Küber-2/+7
Fix #116031.
2023-09-21Auto merge of #114399 - Zalathar:no-renumber, r=jackh726bors-180/+130
coverage: Don't bother renumbering expressions on the Rust side The LLVM API that we use to encode coverage mappings already has its own code for removing unused coverage expressions and renumbering the rest. This lets us get rid of our own complex renumbering code, making it easier to change our coverage code in other ways. --- Now that we have tests for coverage mappings (#114843), I've been able to verify that this PR doesn't make the coverage mappings worse, thanks to an explicit simplification step.
2023-09-21added support for GNU/HurdSamuel Thibault-4/+63
2023-09-21Move `DepKind` to `rustc_query_system` and define it as `u16`John Kåre Alsaker-518/+508
2023-09-21Auto merge of #116010 - RalfJung:more-typed-immediates, r=oli-obkbors-188/+202
interpret: more consistently use ImmTy in operators and casts The diff in src/tools/miri/src/shims/x86/sse2.rs should hopefully suffice to explain why this is nicer. :)
2023-09-21Rollup merge of #115972 - RalfJung:const-consistency, r=oli-obkGuillaume Gomez-470/+438
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`. Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all. However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish... ``@oli-obk`` any ideas?
2023-09-21Rollup merge of #115936 - oli-obk:inline_const_promotion, r=RalfJungGuillaume Gomez-20/+23
Prevent promotion of const fn calls in inline consts We don't wanna make that mistake we did for statics and consts worse by letting more code use it. r? ``@RalfJung`` cc https://github.com/rust-lang/rust/issues/76001
2023-09-21Rollup merge of #115257 - Urgau:invalid-utf8-walk-up-hir, r=NilstriebGuillaume Gomez-11/+62
Improve invalid UTF-8 lint by finding the expression initializer This PR introduce a small mechanism to walk up the HIR through bindings, if/else, consts, ... when trying lint on invalid UTF-8. Fixes https://github.com/rust-lang/rust/issues/115208
2023-09-21Prevent promotion of const fn calls in inline constsOli Scherer-20/+23
2023-09-21coverage: Don't bother renumbering expressions on the Rust sideZalathar-167/+64
The LLVM API that we use to encode coverage mappings already has its own code for removing unused coverage expressions and renumbering the rest. This lets us get rid of our own complex renumbering code, making it easier to change our coverage code in other ways.
2023-09-21coverage: Explicitly simplify coverage expressions in codegenZalathar-1/+57
After coverage instrumentation and MIR transformations, we can sometimes end up with coverage expressions that always have a value of zero. Any expression operand that refers to an always-zero expression can be replaced with a literal `Operand::Zero`, making the emitted coverage mapping data smaller and simpler. This simplification step is mostly redundant with the simplifications performed inline in `expressions_with_regions`, except that it does a slightly more thorough job in some cases (because it checks for always-zero expressions *after* other simplifications). However, adding this simplification step will then let us greatly simplify that code, without affecting the quality of the emitted coverage maps.
2023-09-21coverage: Make the zero counter a constantZalathar-15/+12
2023-09-21Improve invalid UTF-8 lint by finding the expression initializerUrgau-11/+14
2023-09-21reviewlcnr-78/+75
2023-09-21wlcnr-1/+1
2023-09-21slight refactor, add commentlcnr-11/+20
2023-09-21HACK: avoid hang in structurally_normalizelcnr-3/+9
2023-09-21proof trees: use for `intercrate_ambiguity_causes`lcnr-221/+757
2023-09-21rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::ConstRalf Jung-426/+407
2023-09-21try to avoid some layout_of callsRalf Jung-37/+42
2023-09-21Auto merge of #115549 - saethlin:include-bytes-resilient, r=jackh726bors-2/+58
Fall back to the unoptimized implementation in read_binary_file if File::metadata lies Fixes https://github.com/rust-lang/rust/issues/115458 r? `@jackh726` because you approved the previous PR
2023-09-20Add unit tests based on files that return odd sizes to statBen Kimock-0/+27
2023-09-20Auto merge of #115542 - saethlin:fileencoder-is-bufwriter, r=WaffleLapkinbors-214/+113
Simplify/Optimize FileEncoder FileEncoder is basically a BufWriter except that it exposes access to the not-written-to-yet region of the buffer so that some users can write directly to the buffer. This strategy is awesome because it lets us avoid calling memcpy for small copies, but the previous strategy was based on the writer accessing a `&mut [MaybeUninit<u8>; N]` and returning a `&[u8]` which is an API which currently mandates the use of unsafe code, making that interface in general not that appealing. So this PR cleans up the FileEncoder implementation and builds on that general idea of direct buffer access in order to prevent `memcpy` calls in a few key places when encoding the dep graph and rmeta tables. The interface used here is now 100% safe, but with the caveat that internally we need to avoid trusting the number of bytes that the provided function claims to have written. The original primary objective of this PR was to clean up the FileEncoder implementation so that the fix for the following issues would be easy to implement. The fix for these issues is to correctly update self.buffered even when writes fail, which I think it's easy to verify manually is now done, because all the FileEncoder methods are small. Fixes https://github.com/rust-lang/rust/issues/115298 Fixes https://github.com/rust-lang/rust/issues/114671 Fixes https://github.com/rust-lang/rust/issues/114045 Fixes https://github.com/rust-lang/rust/issues/108100 Fixes https://github.com/rust-lang/rust/issues/106787
2023-09-20PR feedbackBen Kimock-36/+55
2023-09-20stronger consistency check in ImmTy::from_immediateRalf Jung-3/+11
2023-09-20interpret: less debug-printing of typesRalf Jung-39/+29
2023-09-20interpret: more consistently use ImmTy in operators and castsRalf Jung-124/+135
2023-09-20Auto merge of #115987 - loongarch-rs:fix-transparent-union-abi, r=bjorn3bors-0/+11
rustc_target/loongarch: Fix passing of transparent unions with only one non-ZST member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes https://github.com/rust-lang/rust/issues/115509 r? `@bjorn3`
2023-09-20Auto merge of #115870 - RalfJung:const-value-slice, r=oli-obkbors-62/+74
adjust ConstValue::Slice to work for arbitrary slice types valtrees have already been assuming that this works; this PR makes it a reality. Also further restrict `ConstValue::Slice` to what it is actually used for; this even shrinks `ConstValue` from 32 to 24 bytes which is a nice win. :) The alternative to this approach is to make `ConstValue::Slice` work really only for `&str`/`&[u8]` literals, and never return it in `op_to_const`. That would make `op_to_const` very clean. We could then even remove the `meta` field; the length would always be `data.inner().len()`. We could *almost* just use a `Symbol` instead of a `ConstAllocation`, but we have to support byte strings and there doesn't seem to be an interned representation of them (or rather, `ConstAllocation` *is* their interned representation). In this world, valtrees of slice reference types would then become noticeably more expensive to turn into a `ConstValue` -- but does that matter? Specifically for `&str`/`&[u8]` we could still use the optimized representation if we wanted. If byte strings were already interned somewhere I'd gravitate towards the alternative, but the way things stand, we need a `ConstAllocation` case anyway to support byte strings, and then we might as well support arbitrary slices. (Or we say that byte strings don't get an optimized representation at all. Such a performance cliff between `str` and byte strings is probably unexpected, though due to the lack of interning for byte strings I think there might already be a performance cliff there.)
2023-09-20Validate crate name in CLI option --externLeón Orell Valerian Liehr-0/+31
2023-09-20Rollup merge of #115962 - Zalathar:debug, r=oli-obkGuillaume Gomez-1048/+38
coverage: Remove debug code from the instrumentor The coverage instrumentor has an entire module full of complex code that is only used for debugging. And as I continue to work on coverage, I keep finding that this debug code is constantly causing more trouble than it's worth. It's deeply entangled with current implementation details, such that making any non-trivial change to the instrumentor usually requires major changes to the debug code. And so far I have personally not found any of this debug code to be *useful*. In light of that situation, I'd like to try just ripping all of it out. If I spend any more time dealing with coverage debug code, I want it to be because I'm writing new and useful tools, not dutifully maintaining a boat-anchor that quite plausibly isn't being used by anyone at all. --- r? `@ghost` `@rustbot` label +A-code-coverage --- [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Removing.20debug.20code.20from.20the.20coverage.20instrumentor)
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 08:05:22 +0000