about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2023-11-18Remove unneeded `unknown` variable and `Symbol` creation when iterating over ↵Guillaume Gomez-4/+4
items in rustdoc rendering
2023-11-18Auto merge of #118002 - nnethercote:unify-input-no-input, r=bjorn3bors-109/+80
Unify "input" and "no input" paths in `run_compiler` A follow-up to #117649. r? `@bjorn3`
2023-11-18Auto merge of #118037 - weihanglo:update-cargo, r=weihanglobors-0/+0
Update cargo 11 commits in 2c03e0e2dcd05dd064fcf10cc1050d342eaf67e3..9765a449d9b7341c2b49b88da41c2268ea599720 2023-11-16 04:21:44 +0000 to 2023-11-17 20:58:23 +0000 - refactor(toml): Clean up workspace inheritance (rust-lang/cargo#12971) - docs: Recommend a wider selection of libsecret-compatible password managers (rust-lang/cargo#12993) - feat(cli): add color output for `cargo --list` (rust-lang/cargo#12992) - refactor: log when loading config from file (rust-lang/cargo#12991) - Link to rustc lint levels (rust-lang/cargo#12990) - chore(ci): Catch naive use of AtomicU64 early (rust-lang/cargo#12988) - cargo-credential-1password: Add missing `--account` argument to `op signin` command (rust-lang/cargo#12985) - chore: dogfood Cargo `-Zlints` table feature (rust-lang/cargo#12178) - cargo-credential-1password: Fix README (rust-lang/cargo#12986) - Fix a rustflags test using a wrong buildfile name (rust-lang/cargo#12987) - Fix some test output validation. (rust-lang/cargo#12982) r? ghost
2023-11-18Update cargoWeihang Lo-0/+0
2023-11-18Auto merge of #117525 - GKFX:remove_option_payload_ptr, r=petrochenkovbors-171/+16
Remove option_payload_ptr; redundant to offset_of The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at https://github.com/rust-lang/rust/issues/106655#issuecomment-1790907626). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
2023-11-18Update based on petrochenkov's reviewGeorge Bateman-3/+4
2023-11-18Auto merge of #117924 - estebank:issue-53841, r=petrochenkovbors-0/+22
When a local binding shadows a fn, point at fn def in call failure When a local binding shadows a function that is then called, this local binding will cause an E0618 error. We now point not only at the binding definition, but also at the locally defined function of the same name. ``` error[E0618]: expected function, found `&str` --> $DIR/issue-22468.rs:3:13 | LL | let foo = "bar"; | --- `foo` has type `&str` LL | let x = foo("baz"); | ^^^------- | | | call expression requires function ... LL | fn foo(file: &str) -> bool { | -------------------------- this function of the same name is available here, but it shadowed by the local binding of the same name ``` Fix #53841
2023-11-18Auto merge of #115412 - eswartz:docs/total_cmp-test-result-in-docs, r=scottmcmbors-6/+22
Expose tests for {f32,f64}.total_cmp in docs Expose tests for {f32,f64}.total_cmp in docs Uncomment the helpful `assert_eq!` line, which is stripped out completely in docs, and leaves the reader to mentally play through the algorithm, or go to the playground and add a println!, to see what the result will be. (If these tests are known to fail on some platforms, is there some mechanism to conditionalize this or escape the test so the `assert_eq!` source will be visible on the web? I am a newbie, which is why I was reading docs ;)
2023-11-18Auto merge of #115249 - clarfonthey:alignment, r=scottmcmbors-1/+44
impl more traits for ptr::Alignment, add mask method Changes: * Adds `rustc_const_unstable` attributes where missing * Makes `log2` method const * Adds `mask` method * Implements `Default`, which is equivalent to `Alignment::MIN` No longer included in PR: * Removes indirection of `AlignmentEnum` type alias (this was intentional) * Implements `Display`, `Binary`, `Octal`, `LowerHex`, and `UpperHex` (should go through libs-api instead) * Controversially implements `LowerExp` and `UpperExp` using `p` instead of `e` to indicate a power of 2 (also should go through libs-api) Tracking issue for `ptr::Alignment`: #102070
2023-11-18impl more traits for ptr::Alignment, add mask methodltdk-1/+44
2023-11-18Auto merge of #117825 - fee1-dead-contrib:corefx, r=petrochenkovbors-2/+23
Reenable effects in libcore With #116670, #117531, and #117171, I think we would be comfortable with re-enabling the effects feature for more testing in libcore. r? `@oli-obk` cc `@fmease` cc #110395
2023-11-18Auto merge of #117742 - ↵bors-17/+219
weiznich:turn_overlapping_diagnostic_options_into_warnings, r=compiler-errors Add some additional warnings for duplicated diagnostic items This commit adds warnings if a user supplies several diagnostic options where we can only apply one of them. We explicitly warn about ignored options here. In addition a small test for these warnings is added. r? `@compiler-errors` For now that's the last PR to improve the warnings generated by misused `#[diagnostic::on_unimplemented]` attributes. I'm not sure what needs to be done next to move this closer to stabilization.
2023-11-18Auto merge of #117138 - zachs18:rwlock_guard_debug_unsized, r=dtolnaybors-2/+2
Add T: ?Sized to `RwLockReadGuard` and `RwLockWriteGuard`'s Debug impls. For context, `MutexGuard` has `+ ?Sized` on its `Debug` impl, and all three have `+ ?Sized` on their `Display` impls. It looks like the `?Sized` was just missed when the impls were added (the impl for `MutexGuard` was added in the same PR (https://github.com/rust-lang/rust/pull/38006) with support for `T: Debug + ?Sized`, and `RwLock*Guard`s did allow `T: ?Sized` types already); the `Display` impls were added later (https://github.com/rust-lang/rust/pull/42822) with support for `T: Debug + ?Sized` types. I think this needs a T-libs-api FCP? I'm not sure if this also needs an ACP. If so I can make one. These are changes to (stable) trait impls on stable types so will be insta-stable. `@rustbot` label +T-libs-api
2023-11-18When a local binding shadows a fn, point at fn def in call failureEsteban Küber-0/+22
When a local binding shadows a function that is then called, this local binding will cause an E0618 error. We now point not only at the binding definition, but also at the locally defined function of the same name. ``` error[E0618]: expected function, found `&str` --> $DIR/issue-22468.rs:3:13 | LL | let foo = "bar"; | --- `foo` has type `&str` LL | let x = foo("baz"); | ^^^------- | | | call expression requires function ... LL | fn foo(file: &str) -> bool { | -------------------------- this function of the same name is avalable here, but it shadowed by the local binding of the same name ``` Fix #53841
2023-11-17Auto merge of #118023 - matthiaskrgr:rollup-i9skwic, r=matthiaskrgrbors-304/+644
Rollup of 7 pull requests Successful merges: - #117338 (Remove asmjs) - #117549 (Use `copied` instead of manual `map`) - #117745 (Emit smir) - #117964 (When using existing fn as module, don't claim it doesn't exist) - #118006 (clarify `fn discriminant` guarantees: only free lifetimes may get erased) - #118016 (Add stable mir members to triagebot config) - #118022 (Miri subtree update) r? `@ghost` `@rustbot` modify labels: rollup
2023-11-17Rollup merge of #118022 - saethlin:miri, r=saethlinMatthias Krüger-138/+252
Miri subtree update
2023-11-17Rollup merge of #118016 - celinval:main, r=compiler-errorsMatthias Krüger-0/+9
Add stable mir members to triagebot config I also added the two crates from the project to `[assign.owners]` so it automatically assign to a project member changes to those crates.
2023-11-17Rollup merge of #118006 - lcnr:discriminant-docs, r=compiler-errorsMatthias Krüger-4/+6
clarify `fn discriminant` guarantees: only free lifetimes may get erased cc https://github.com/rust-lang/rust/pull/104299/files#r1397082347 don't think this necessitates a backport by itself, but should imo be included if one were to exist. r? types
2023-11-17Rollup merge of #117964 - estebank:issue-81232, r=petrochenkovMatthias Krüger-4/+16
When using existing fn as module, don't claim it doesn't exist Tweak wording of module not found in resolve, when the name exists but belongs to a non-`mod` item. Fix #81232.
2023-11-17Rollup merge of #117745 - ouz-a:emit_smir, r=celinvalMatthias Krüger-9/+340
Emit smir This adds ability to `-Zunpretty=smir` and get smir output of a Rust file, this is obliviously pretty basic compared to `mir` output but I think we could iteratively improve it, and even at this state this is useful for us. r? ``@celinval``
2023-11-17Rollup merge of #117549 - DaniPopes:more-copied, r=b-naberMatthias Krüger-11/+10
Use `copied` instead of manual `map`
2023-11-17Rollup merge of #117338 - workingjubilee:asmjs-meets-thanatos, r=b-naberMatthias Krüger-138/+11
Remove asmjs Fulfills [MCP 668](https://github.com/rust-lang/compiler-team/issues/668). `asmjs-unknown-emscripten` does not work as-specified, and lacks essential upstream support for generating asm.js, so it should not exist at all.
2023-11-17Auto merge of #114292 - estebank:issue-71039, r=b-naberbors-67/+200
More detail when expecting expression but encountering bad macro argument On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred. Fix #71039. ``` error: expected expression, found pattern `1 + 1` --> $DIR/trace_faulty_macros.rs:49:37 | LL | (let $p:pat = $e:expr) => {test!(($p,$e))}; | ------- -- this is interpreted as expression, but it is expected to be pattern | | | this macro fragment matcher is expression ... LL | (($p:pat, $e:pat)) => {let $p = $e;}; | ------ ^^ expected expression | | | this macro fragment matcher is pattern ... LL | test!(let x = 1+1); | ------------------ | | | | | this is expected to be expression | in this macro invocation | = note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens = note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info) ```
2023-11-18Simplify `run_compiler` control flow.Nicholas Nethercote-72/+54
I find `Compilation::and_then` hard to read. This commit removes it, simplifying the control flow in `run_compiler`, and reducing the number of lines of code. In particular, `list_metadata` and `process_try_link` (renamed `rlink`) are now only called if the relevant condition is true, rather than that condition being checked within the function.
2023-11-18Factor out two `print_crate_info` calls.Nicholas Nethercote-2/+3
2023-11-18Move `describe_lints` calls.Nicholas Nethercote-9/+9
Currently we have an inconsistency between the "input" and "no input" cases: - no input: `rustc --print=sysroot -Whelp` prints the lint help. - input: `rustc --print=sysroot -Whelp a.rs` prints the sysroot. It makes sense to print the lint help in both cases, because that's what happens with `--help`/`-Zhelp`/`-Chelp`. In fact, the `describe_lints` in the "input" case happens amazingly late, after *parsing*. This is because, with plugins, lints used to be registered much later, when the global context was created. But #117649 moved lint registration much earlier, during session construction. So this commit moves the `describe_lints` call to a single spot for both for both the "input" and "no input" cases, as early as possible. This is still not as early as `--help`/`-Zhelp`/`-Chelp`, because `-Whelp` must wait until the session is constructed.
2023-11-18Merge `interface::run_compiler` calls.Nicholas Nethercote-30/+18
`rustc_driver_impl::run_compiler` currently has two `interface::run_compiler` calls: one for the "no input" case, and one for the normal case. This commit merges the former into the latter, which makes the control flow easier to read and avoids some duplication. It also makes it clearer that the "no input" case will describe lints before printing crate info, while the normal case does it in the reverse order. Possibly a bug?
2023-11-17use new apis and add new functionouz-a-17/+20
2023-11-18Rename `early_error_handler` as `default_handler`.Nicholas Nethercote-9/+9
Yes, its type is `EarlyErrorHandler`, but there is another value of that type later on in the function called `handler` that is initialized with `sopts.error_format`. So `default_handler` is a better name because it clarifies that it is initialized with `ErrorOutputType::default()`.
2023-11-17Add stable mir members to triagebot configCelina G. Val-0/+9
2023-11-17Auto merge of #111922 - vaporoxx:feat-searcher, r=dtolnaybors-0/+4
feat: implement `DoubleEndedSearcher` for `CharArray[Ref]Searcher` This PR implements `DoubleEndedSearcher` for both `CharArraySearcher` and `CharArrayRefSearcher`. I'm not sure whether this was just overlooked or if there is a reason for it, but since it behaves exactly like `CharSliceSearcher`, I think the implementations should be appropriate.
2023-11-17Auto merge of #117993 - nnethercote:streamline-Linker, r=bjorn3bors-64/+42
Streamline `Linker` r? `@bjorn3`
2023-11-17Auto merge of #117944 - lcnr:region-refactor-uwu, r=BoxyUwUbors-120/+93
some additional region refactorings the commits are selfcontained ✨ r? `@BoxyUwU`
2023-11-17Auto merge of #112422 - aliemjay:implied-bounds-placeholders, r=lcnrbors-3/+81
ignore implied bounds with placeholders given the following code: ```rust trait Trait { type Ty<'a> where Self: 'a; } impl<T> Trait for T { type Ty<'a> = () where Self: 'a; } struct Foo<T: Trait>(T) where for<'x> T::Ty<'x>: Sized; ``` when computing the implied bounds from `Foo<X>` we incorrectly get the bound `X: !x` from the normalization of ` for<'x> <X as Trait>::Ty::<'x>: Sized`. This is a a known bug! we shouldn't use the constraints that arise from normalization as implied bounds. See #109628. Ignore these bounds for now. This should prevent later ICEs. Fixes #112250 Fixes #107409
2023-11-17only free lifetimes may get erasedlcnr-4/+6
2023-11-17move pretty into stable_mirOğuz Ağcayazı-305/+308
2023-11-17change smir to StableMirOğuz Ağcayazı-23/+35
2023-11-17remove unwrapOğuz Ağcayazı-10/+15
2023-11-17better formatting for statementsOğuz Ağcayazı-25/+49
2023-11-17cover statementsOğuz Ağcayazı-26/+155
2023-11-17emit basic smirOğuz Ağcayazı-5/+160
2023-11-17Auto merge of #117278 - lcnr:try-normalize-ty, r=compiler-errorsbors-316/+410
new solver normalization improvements cool beans At the core of this PR is a `try_normalize_ty` which stops for rigid aliases by using `commit_if_ok`. Reworks alias-relate to fully normalize both the lhs and rhs and then equate the resulting rigid (or inference) types. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/68 by avoiding the exponential blowup. Also supersedes #116369 by only defining opaque types if the hidden type is rigid. I removed the stability check in `EvalCtxt::evaluate_goal` due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/75. While I personally have opinions on how to fix it, that still requires further t-types/`@nikomatsakis` buy-in, so I removed that for now. Once we've decided on our approach there, we can revert this commit. r? `@compiler-errors`
2023-11-17rename bound region instantiationlcnr-69/+78
- `erase_late_bound_regions` -> `instantiate_bound_regions_with_erased` - `replace_late_bound_regions_X` -> `instantiate_bound_regions_X`
2023-11-17replace unnecessary folder impls with fold_regionlcnr-51/+15
2023-11-17Auto merge of #118003 - matthiaskrgr:rollup-80t3uky, r=matthiaskrgrbors-80/+784
Rollup of 3 pull requests Successful merges: - #115476 (document ABI compatibility) - #117688 (Misc changes to StableMIR required to Kani use case.) - #117998 (On resolve error of `[rest..]`, suggest `[rest @ ..]`) r? `@ghost` `@rustbot` modify labels: rollup
2023-11-17Rollup merge of #117998 - estebank:issue-88404, r=TaKO8KiMatthias Krüger-0/+84
On resolve error of `[rest..]`, suggest `[rest @ ..]` When writing a pattern to collect multiple entries of a slice in a single binding, it is easy to misremember or typo the appropriate syntax to do so, instead writing the experimental `X..` pattern syntax. When we encounter a resolve error because `X` isn't available, we suggest `X @ ..` as an alternative. ``` error[E0425]: cannot find value `rest` in this scope --> $DIR/range-pattern-meant-to-be-slice-rest-pattern.rs:3:13 | LL | [1, rest..] => println!("{rest:?}"), | ^^^^ not found in this scope | help: if you meant to collect the rest of the slice in `rest`, use the at operator | LL | [1, rest @ ..] => println!("{rest:?}"), | + ``` Fix #88404.
2023-11-17Rollup merge of #117688 - celinval:smir-kani-reach, r=compiler-errorsMatthias Krüger-72/+583
Misc changes to StableMIR required to Kani use case. First, I wanted to say that I can split this review into multiple if it makes reviewing easier. I bundled them up, since I've been testing them together (See https://github.com/rust-lang/project-stable-mir/pull/51 for the set of more thorough checks). So far, this review includes 3 commits: 1. Add more APIs and fix `Instance::body` - Add more APIs to retrieve information about types. - Add a few more instance resolution options. For the drop shim, we return None if the drop body is empty. Not sure it will be enough. - Make `Instance::body()` return an Option<Body>, since not every instance might have an available body. For example, foreign instances, virtual instances, dependencies. 2. Fix a bug on MIRVisitor - We were not iterating over all local variables due to a typo. 3. Add more SMIR internal impl and callback return value - In cases like Kani, we will invoke the rustc_internal run command directly for now. It would be handly to be able to have a callback that can return a value. - We also need extra methods to convert stable constructs into internal ones, so we can break down the transition into finer grain commits. - For the internal implementation of Region, we're always returning `ReErased` for now.
2023-11-17Rollup merge of #115476 - RalfJung:abi-compat-docs, r=Mark-SimulacrumMatthias Krüger-8/+117
document ABI compatibility I don't think we have any central place where we document our ABI compatibility rules, so let's create one. The `fn()` pointer type seems like a good place since ABI questions can only become relevant when invoking a function through a function pointer. This will likely need T-lang FCP.
2023-11-17linking in general has more pitfalls than just call ABIRalf Jung-2/+3
2023-11-17Make `Compiler::sess` private.Nicholas Nethercote-2/+2
Like `Compiler::codegen_backend`.