about summary refs log tree commit diff
path: root/compiler/rustc_session/src
AgeCommit message (Collapse)AuthorLines
2022-02-06Delete query statsMark Rousskov-2/+0
These statistics are computable from the self-profile data and/or ad-hoc collectable as needed, and in the meantime contribute to rustc bootstrap times.
2022-02-04Rollup merge of #93608 - nnethercote:speed-up-find_library_crate, r=petrochenkovMatthias Krüger-46/+14
Clean up `find_library_crate` Some clean-ups. r? `@petrochenkov`
2022-02-04Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage, ↵Matthias Krüger-18/+51
r=wesleywiser Stabilize `-Z instrument-coverage` as `-C instrument-coverage` (Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121) This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.) Many, many people have tested this support, and there are numerous reports of it working as expected. Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option. Addressing questions raised in the tracking issue: > If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.) This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration. > The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline? This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version). > The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM. Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement. The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization. The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.
2022-02-02Make `SearchPathFile::file_name_str` non-optional.Nicholas Nethercote-13/+13
Currently, it can be `None` if the conversion from `OsString` fails, in which case all searches will skip over the `SearchPathFile`. The commit changes things so that the `SearchPathFile` just doesn't get created in the first place. Same behaviour, but slightly simpler code.
2022-02-02Inline and remove `FileSearch::search`.Nicholas Nethercote-14/+1
It has only a single callsite, and having all the code in one place will make it possible to optimize the search.
2022-02-02Remove `FileMatch`.Nicholas Nethercote-12/+2
It's returned from `FileSearch::search` but it's only used to print some debug info.
2022-02-02Remove rlib special-casing in `FileSearch::search`.Nicholas Nethercote-10/+1
This code and comment appear to be out of date. `CrateLocator::find_library_crate` is the only caller of this function and it handles rlib vs dylib overlap itself (see `CrateLocator::extract_lib`) after inspecting all the files present, so it doesn't need to see them in any particular order.
2022-02-01Add missing | between print optionsDaniel Frampton-1/+1
2022-02-01add a rustc::query_stability lintlcnr-0/+1
2022-01-23Rollup merge of #93229 - mark-i-m:noquiet, r=eddybMatthias Krüger-4/+0
Remove DiagnosticBuilder.quiet r? `@eddyb` cc https://github.com/rust-lang/rust/issues/69426 `@GuillaumeGomez` `@Manishearth`
2022-01-23Remove DiagnosticBuilder.quietmark-4/+0
2022-01-21Gate `l4-bender` linker flavorVadim Petrochenkov-1/+11
2022-01-20Rollup merge of #91606 - joshtriplett:stabilize-print-link-args, r=pnkfelixMatthias Krüger-3/+4
Stabilize `-Z print-link-args` as `--print link-args` We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments. Add documentation for the new option. In the documentation, make it clear that the *exact* format of the output is not a stable guarantee.
2022-01-18Rollup merge of #90782 - ricobbe:binutils-dlltool, r=michaelwoeristerMatthias Krüger-0/+2
Implement raw-dylib support for windows-gnu Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801. (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of #58713.
2022-01-12Call out to binutils' dlltool for raw-dylib on windows-gnu platforms.Richard Cobbe-0/+2
2022-01-09Stabilize -Z print-link-args as --print link-argsJosh Triplett-3/+4
We have stable options for adding linker arguments; we should have a stable option to help debug linker arguments.
2022-01-06sess/cg: re-introduce split dwarf kindDavid Wood-6/+72
In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split, respectively. On Unix, `-C split-debuginfo=packed` will put debuginfo into object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo into dwarf object files and won't package it. In the initial implementation of Split DWARF, split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode, sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However, both split and single modes could be packaged or not, the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). This commit re-introduces a `-Z split-dwarf-kind` flag, which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). Signed-off-by: David Wood <david.wood@huawei.com>
2022-01-01Require `-Zunstable-options` for `-C instrument-coverage=except-*` optionsJosh Triplett-4/+11
These options primarily exist to work around bugs, and those bugs have largely been fixed. Avoid stabilizing them, so that we don't have to support them indefinitely.
2022-01-01Stabilize -Z instrument-coverage as -C instrument-coverageJosh Triplett-17/+43
Continue supporting -Z instrument-coverage for compatibility for now, but show a deprecation warning for it. Update uses and documentation to use the -C option. Move the documentation from the unstable book to stable rustc documentation.
2022-01-01Update references to `-Z symbol-mangling-version` to use `-C`Josh Triplett-1/+1
Replace `-Z symbol-mangling-version=v0` with `-C symbol-mangling-version=v0`. Replace `-Z symbol-mangling-version=legacy` with `-Z unstable-options -C symbol-mangling-version=legacy`.
2022-01-01Stabilize -Z symbol-mangling-version as -C symbol-mangling-versionJosh Triplett-10/+39
This allows selecting `v0` symbol-mangling without an unstable option. Selecting `legacy` still requires -Z unstable-options. Continue supporting -Z symbol-mangling-version for compatibility for now, but show a deprecation warning for it.
2021-12-31Auto merge of #92175 - Aaron1011:fix-missing-source-file, r=cjgillotbors-0/+6
Import `SourceFile`s from crate before decoding foreign `Span` Fixes #92163 Fixes #92014 When writing to the incremental cache, we encode all `Span`s we encounter, regardless of whether or not their `SourceFile` comes from the local crate, or from a foreign crate. When we decode a `Span`, we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate, then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion, when we try to resolve definitions from other crates. In certain cases, however, we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate, leading to an ICE. This PR fixes the issue by enconding the `SourceFile`'s `CrateNum` when we encode a `Span`. During decoding, we call `imported_source_files()` when we encounter a foreign `CrateNum`, which ensure that all `SourceFile`s from that crate are imported into the current session.
2021-12-29Auto merge of #88354 - Jmc18134:hint-space-pauth-opt, r=nagisabors-3/+58
Add codegen option for branch protection and pointer authentication on AArch64 The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets.
2021-12-23Import `SourceFile`s from crate before decoding foreign `Span`Aaron Hill-0/+6
Fixes #92163 Fixes #92014 When writing to the incremental cache, we encode all `Span`s we encounter, regardless of whether or not their `SourceFile` comes from the local crate, or from a foreign crate. When we decode a `Span`, we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate, then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion, when we try to resolve definitions from other crates. In certain cases, however, we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate, leading to an ICE. This PR fixes the issue by calling `imported_source_files()` when we encounter a `SourceFile` with a foreign `CrateNum`. This ensures that all `SourceFile`s from that crate are imported into the current session.
2021-12-19Auto merge of #92099 - matthiaskrgr:rollup-4gwv67m, r=matthiaskrgrbors-1/+1
Rollup of 7 pull requests Successful merges: - #91141 (Revert "Temporarily rename int_roundings functions to avoid conflicts") - #91984 (Remove `in_band_lifetimes` from `rustc_middle`) - #92028 (Sync portable-simd to fix libcore build for AVX-512 enabled targets) - #92042 (Enable `#[thread_local]` for all windows-msvc targets) - #92071 (Update example code for Vec::splice to change the length) - #92077 (rustdoc: Remove unused `collapsed` field) - #92081 (rustdoc: Remove unnecessary `need_backline` function) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-12-19Rollup merge of #92042 - ChrisDenton:msvc-static-tls, r=nagisaMatthias Krüger-1/+1
Enable `#[thread_local]` for all windows-msvc targets As it stands, `#[thread_local]` is enabled haphazardly for msvc. It seems all 64-bit targets have it enabled, but not 32-bit targets unless they're also UWP targets (perhaps because UWP was added more recently?). So this PR simply enables it for 32-bit targets as well. I can't think of a reason not to and I've confirmed by running tests locally which pass. See also #91659
2021-12-19Auto merge of #91957 - nnethercote:rm-SymbolStr, r=oli-obkbors-1/+1
Remove `SymbolStr` This was originally proposed in https://github.com/rust-lang/rust/pull/74554#discussion_r466203544. As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences. Best reviewed one commit at a time. r? `@oli-obk`
2021-12-19Rollup merge of #91932 - Kixiron:randomize-seed, r=nagisaMatthias Krüger-0/+2
Add user seed to `-Z randomize-layout` Allows users of -`Z randomize-layout` to provide `-Z layout-seed=<seed>` in order to further randomizing type layout randomization. Extension of [compiler-team/#457](https://github.com/rust-lang/compiler-team/issues/457), allows users to change struct layouts without changing code and hoping that item path hashes change, aiding in detecting layout errors
2021-12-17Rename `has_elf_tls` to `has_thread_local`Chris Denton-1/+1
2021-12-15Remove unnecessary sigils around `Symbol::as_str()` calls.Nicholas Nethercote-1/+1
2021-12-14Added -Z layout_seed for allowing user-defined randomization seedsChase Wilson-0/+2
2021-12-14fix clippy::single_char_pattern perf findingsMatthias Krüger-3/+3
2021-12-09Remove redundant [..]sest31-3/+3
2021-12-05Auto merge of #91555 - matthiaskrgr:rollup-pq0iaq7, r=matthiaskrgrbors-5/+16
Rollup of 4 pull requests Successful merges: - #90529 (Skip reborrows in AbstractConstBuilder) - #91437 (Pretty print empty blocks as {}) - #91450 (Don't suggest types whose inner type is erroneous) - #91535 (Stabilize `-Z emit-future-incompat` as `--json future-incompat`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-12-05Rollup merge of #91535 - Aaron1011:stabilize-future-incompat, r=nagisaMatthias Krüger-5/+16
Stabilize `-Z emit-future-incompat` as `--json future-incompat` The FCP was completed in https://github.com/rust-lang/rust/issues/71249
2021-12-05Auto merge of #88611 - m-ou-se:array-into-iter-new-deprecate, r=joshtriplettbors-5/+4
Deprecate array::IntoIter::new.
2021-12-04Stabilize `-Z emit-future-incompat` as `--json future-incompat`Aaron Hill-5/+16
2021-12-04Use IntoIterator for array impl everywhere.Mara Bos-5/+4
2021-12-02Move instrument coverage config getters to `Options`Dylan MacKenzie-6/+18
2021-12-02Move `mir_opt_level` getter into `Options`Dylan MacKenzie-4/+9
2021-12-01Review commentsJamie Cunliffe-5/+4
- Changed the separator from '+' to ','. - Moved the branch protection options from -C to -Z. - Additional test for incorrect branch-protection option. - Remove LLVM < 12 code. - Style fixes. Co-authored-by: James McGregor <james.mcgregor2@arm.com>
2021-12-01Add codegen option for branch protection and pointer authentication on AArch64James McGregor-3/+59
The branch-protection codegen option enables the use of hint-space pointer authentication code for AArch64 targets
2021-11-29Accumulate all values of `-C remark` optionTomasz Miąsko-1/+8
When `-C remark=...` option is specified multiple times, accumulate all values instead of using only the last one.
2021-11-25Rollup merge of #91185 - camelid:rm-force-overflow-checks, r=wesleywiserMatthias Krüger-7/+1
Remove `-Z force-overflow-checks` It was replaced several years ago by the stable option `-C overflow-checks`. The goal was to delete the `-Z` flag once users had migrated [1]. Now that it's been several years, it makes sense to delete the old flag. See also the discussion on Zulip [2]. [1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097 [2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224 r? ```@wesleywiser``` cc ```@RalfJung```
2021-11-25Auto merge of #88781 - estebank:emoji-idents, r=oli-obkbors-1/+7
Tokenize emoji as if they were valid identifiers In the lexer, consider emojis to be valid identifiers and reject them later to avoid knock down parse errors. Partially address #86102.
2021-11-24Remove `-Z force-overflow-checks`Noah Lev-7/+1
It was replaced several years ago by the stable option `-C overflow-checks`. The goal was to delete the `-Z` flag once users had migrated [1]. Now that it's been several years, it makes sense to delete the old flag. See also the discussion on Zulip [2]. [1]: https://github.com/rust-lang/rust/issues/33134#issuecomment-280484097 [2]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/overflow.20checks/near/262497224
2021-11-23review comment: plural of emoji is emojiEsteban Kuber-1/+1
2021-11-23Tokenize emoji as if they were valid indentifiersEsteban Kuber-1/+7
In the lexer, consider emojis to be valid identifiers and reject them later to avoid knock down parse errors.
2021-11-23Rollup merge of #91148 - jhpratt:use-default-enum, r=petrochenkovMatthias Krüger-7/+3
Use `derive_default_enum` in the compiler Let's get this feature some real-world love. ``@rustbot`` label: +C-cleanup +S-waiting-on-review
2021-11-22Use `derive_default_enum` in the compilerJacob Pratt-7/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 06:07:44 +0000