summary refs log tree commit diff
path: root/src
AgeCommit message (Collapse)AuthorLines
2020-10-07Disable ThinLTO for x86_64-unknown-linux-gnuMark Rousskov-1/+1
Temporarily addresses #76980.
2020-10-05Switch channel to stable for 1.47 releaseMark Rousskov-1/+1
2020-10-05Instruct lld that our @ files are posix-style, not WindowsMark Rousskov-0/+6
An upstream LLVM change changed behavior here to respect the host system quoting rules; previously the posix-style format was always used for @files.
2020-10-05Add regression test for SimplifyBranchSame miscompilationTomasz Miąsko-0/+21
2020-10-05Fix miscompile in SimplifyBranchSameSimon Vandel Sillesen-1/+2
2020-10-03repairing broken error message and rustfix application for the new testAurélien Deharbe-10/+28
case
2020-10-03add non-regression test for issue #76597Aurélien Deharbe-0/+21
2020-10-03replacing sub's that can wrap by saturating_sub'sAurélien Deharbe-3/+3
2020-10-03ci: switch to environment files to change the environment on GHAPietro Albini-2/+2
See GitHub's blog post on why the change was necessary: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
2020-10-03cache types during normalizationBastian Kauschke-68/+82
2020-10-03Remove redundancy in cache keyTyler Mandry-5/+4
2020-10-03Intorduced MiniMap - a tiny small storage optimized map implementationValerii Lashmanov-2/+62
This makes everything about 1% faster in rustc-perf, mostly negating performance hit of previous commit.
2020-10-03Better handling for exponential-sized types in misc placesValerii Lashmanov-41/+89
Mostly to fix ui/issues/issue-37311-type-length-limit/issue-37311.rs. Most parts of the compiler can handle deeply nested types with a lot of duplicates just fine, but some parts still attempt to naively traverse type tree. Before such problems were caught by type length limit check, but now these places will have to be changed to handle duplicated types gracefully.
2020-10-03Only visit types once when walking the type treeValerii Lashmanov-39/+192
This fixes #72408. Nested closures were resulting in exponential compilation time. As a performance optimization this change introduces MiniSet, which is a simple small storage optimized set.
2020-10-02Revert "Remove broken clap versions from cargotest"Mark Rousskov-1/+8
This reverts commit eb4d6b520b3e75c7e93f1ea13f1a45eda0687b4e.
2020-10-02Revert "Remove missing_fragment_specifier lint"Mark Rousskov-0/+20
This reverts commit 5ba961018c482e050af908de60e4f8bd1a00f0ae.
2020-10-02Revert "Promote missing_fragment_specifier to hard error"Mark Rousskov-32/+90
This reverts commit 02eae432e7476a0686633a8c2b7cb1d5aab1bd2c.
2020-10-02Revert "Move macro test to ui/macros"Mark Rousskov-0/+0
This reverts commit 84fcd0dc991e2f5b9035d118d8c016f35ab37d0a.
2020-10-01Merge commit 'd28211ddb6bec659acd523ef63966a5032a618b7' into betaflip1995-61/+179
2020-09-28revert const_type_id stabilizationAshley Mannix-4/+7
This reverts commit e3856616ee2a894c7811a7017d98fafa7ba84dd8.
2020-09-28[mir-opt] Disable the `ConsideredEqual` logic in SimplifyBranchSame optWesley Wiser-17/+40
The logic is currently broken and we need to disable it to fix a beta regression (see #76803)
2020-09-28Rebase LLVM onto 11.0.0-rc3Josh Stone-0/+0
2020-09-17Bump to stable releaseMark Rousskov-2/+2
2020-09-17Account for async functions when suggesting new named lifetimeEsteban Küber-12/+39
Fix #75850.
2020-09-17Account for version number in NtIdent hackAaron Hill-10/+56
Issue #74616 tracks a backwards-compatibility hack for certain macros. This has is implemented by hard-coding the filenames and macro names of certain code that we want to continue to compile. However, the initial implementation of the hack was based on the directory structure when building the crate from its repository (e.g. `js-sys/src/lib.rs`). When the crate is build as a dependency, it will include a version number from the clone from the cargo registry (e.g. `js-sys-0.3.17/src/lib.rs`), which would fail the check. This commit modifies the backwards-compatibility hack to check that desired crate name (`js-sys` or `time-macros-impl`) is a prefix of the proper part of the path. See https://github.com/rust-lang/rust/issues/76070#issuecomment-687215646 for more details.
2020-09-17Fix loading pretty-printers in rust-lldb scriptortem-2/+5
2020-09-17Fix HashMap visualizers in Visual Studio (Code)MaulingMonkey-2/+2
CDB doesn't care that you're using static_cast between unrelated types. VS(C) does. These should've been reinterpret_cast or C casts. Cast is from e.g. `u8*` to `tuple<$T1, $T2>*`
2020-09-17Ignore rustc_private items from std docsLzu Tao-9/+20
Apply suggestions from code review Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-09-17Add ui test for 74672 and 76571Lzu Tao-0/+46
These tests will fall without the next commit.
2020-08-31[beta] Update cargoEric Huss-0/+0
2020-08-28Fix swapped stability attributesJoshua Nelson-6/+6
This fixes a regression introduced in https://github.com/rust-lang/rust/pull/74855.
2020-08-25this is beta 1.47.0Pietro Albini-6/+6
2020-08-25Auto merge of #74275 - wesleywiser:break_up_partitioning_rs, r=pnkfelixbors-1012/+1097
Refactor the partitioning module to make it easier to introduce new algorithms I've split the `librustc_mir::monomorphize::partitioning` module into a few files and introduced a `Partitioner` trait which allows us to decouple the partitioning algorithm from the code which integrates it into the query system. This should allow us to introduce new partitioning algorithms much more easily. I've also gone ahead and added a `-Z` flag to control which algorithm is used (currently there is only the `default`). I left a few comments in places where things might be improved further. r? @pnkfelix cc @rust-lang/wg-incr-comp
2020-08-25Auto merge of #75908 - pietroalbini:ci-bump-llvm, r=Mark-Simulacrumbors-7/+12
Bump LLVM on CI to 10.0.0 This PR bumps the LLVM version we use on our macOS and Windows CI to 10.0.0, fixing a breakage we noticed today: ``` 2020-08-25T14:24:28.5939568Z FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/AMDGPUMetadata.cpp.obj 2020-08-25T14:24:28.5940317Z D:\a\rust\rust\build\bootstrap\debug\sccache-plus-cl.exe /nologo -TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib\Support -ID:\a\rust\rust\src\llvm-project\llvm\lib\Support -Iinclude -ID:\a\rust\rust\src\llvm-project\llvm\include -nologo -MT -Brepro --target=x86_64-pc-windows-msvc /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /Brepro /W4 -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-noexcept-type -Wno-comment /Gw /MT /O2 /Ob2 -UNDEBUG -std:c++14 /EHs-c- /GR- /showIncludes /Folib\Support\CMakeFiles\LLVMSupport.dir\AMDGPUMetadata.cpp.obj /Fdlib\Support\CMakeFiles\LLVMSupport.dir\LLVMSupport.pdb -c D:\a\rust\rust\src\llvm-project\llvm\lib\Support\AMDGPUMetadata.cpp 2020-08-25T14:24:28.5940861Z clang-cl: warning: argument unused during compilation: '-Brepro' [-Wunused-command-line-argument] 2020-08-25T14:24:28.5941076Z clang-cl: warning: argument unused during compilation: '-Brepro' [-Wunused-command-line-argument] 2020-08-25T14:24:28.5941321Z In file included from D:\a\rust\rust\src\llvm-project\llvm\lib\Support\AMDGPUMetadata.cpp:15: 2020-08-25T14:24:28.5941545Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/Twine.h:12: 2020-08-25T14:24:28.5941774Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/SmallVector.h:16: 2020-08-25T14:24:28.5942016Z In file included from D:\a\rust\rust\src\llvm-project\llvm\include\llvm/ADT/iterator_range.h:21: 2020-08-25T14:24:28.5942257Z In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\iterator:9: 2020-08-25T14:24:28.5942542Z C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include\yvals_core.h(494,2): error: STL1000: Unexpected compiler version, expected Clang 10.0.0 or newer. ``` I uploaded both the new tarballs to our mirrors bucket.
2020-08-25ci: fix macOS target name for LLVM 10Pietro Albini-3/+3
2020-08-25ci: bump LLVM source tarball on Linux to 10.0.0Pietro Albini-1/+1
2020-08-25ci: bump prebuilt LLVM on macOS and Windows to 10.0.0Pietro Albini-6/+11
2020-08-25Auto merge of #75773 - matklad:snapshot-tests, r=Mark-Simulacrumbors-0/+56
Introduce expect snapshot testing library into rustc Snapshot testing is a technique for writing maintainable unit tests. Unlike usual `assert_eq!` tests, snapshot tests allow to *automatically* upgrade expected values on test failure. In a sense, snapshot tests are inline-version of our beloved UI-tests. Example: ![expect](https://user-images.githubusercontent.com/1711539/90888810-3bcc8180-e3b7-11ea-9626-d06e89e1a0bb.gif) A particular library we use, `expect_test` provides an `expect!` macro, which creates a sort of self-updating string literal (by using `file!` macro). Self-update is triggered by setting `UPDATE_EXPECT` environmental variable (this info is printed during the test failure). This library was extracted from rust-analyzer, where we use it for most of our tests. There are some other, more popular snapshot testing libraries: * https://github.com/mitsuhiko/insta * https://github.com/aaronabramov/k9 The main differences of `expect` are: * first-class snapshot objects (so, tests can be written as functions, rather than as macros) * focus on inline-snapshots (but file snapshots are also supported) * restricted feature set (only `assert_eq` and `assert_debug_eq`) * no extra runtime (ie, no `cargo insta`) See rust-analyzer/rust-analyzer#5101 for a an extended comparison. It is unclear if this testing style will stick with rustc in the long run. At the moment, rustc is mainly tested via integrated UI tests. But in the library-ified world, unit-tests will become somewhat more important (that's why use use `rustc_lexer` library-ified library as an example in this PR). Given that the cost of removal shouldn't be too high, it probably makes sense to just see if this flies!
2020-08-25Auto merge of #75132 - scottmcm:stabilize-range-is-empty, r=dtolnaybors-5/+3
Stabilize Range[Inclusive]::is_empty I would like to propose these two simple methods for stabilization: - Knowing that a range is exhausted isn't otherwise trivial - Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable - These work on `PartialOrd`, consistently with the stable `contains` method, and are thus more general than iterator-based approaches that need `Step` - They've been unchanged for some time, and have picked up uses in the compiler - Stabilizing them doesn't block any future iterator-based `is_empty` plans, as these inherent ones are preferred in name resolution https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty Closes #48111
2020-08-25Auto merge of #75764 - workingjubilee:tidy-up-cargo-metadata, r=Mark-Simulacrumbors-1/+1
bump tidy to cargo_metadata 0.11 Updates cargo_metadata in tidy's Cargo.toml from 0.9.1 to 0.11 Real version change 0.9.11 -> 0.11.1 https://github.com/oli-obk/cargo_metadata/compare/v0.9.1...v0.11.1
2020-08-25Auto merge of #75666 - davidtwco:tidy-lang-items, r=varkorbors-299/+277
hir: consistent use and naming of lang items This PR adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or "LangItem". In addition, lang item variants are no longer exported from the `lang_items` module. This is certainly subjective and while I think this is an improvement, if many in the team don't then we can just close this.
2020-08-24Unbreak the clippy testScott McMurray-1/+3
2020-08-24Auto merge of #75625 - mati865:mingw-cross-compile, r=Mark-Simulacrumbors-1/+10
Fix windows-gnu host cross-compilation Fixes https://github.com/rust-lang/rust/issues/64218 Also turns out it's faster to run Linux virtual machine on Windows and cross-compile `./x.py dist` than doing it on Windows directly...
2020-08-24Stabilize Range[Inclusive]::is_emptyScott McMurray-4/+0
I would like to propose these two simple methods for stabilization: - Knowing that a range is exhaused isn't otherwise trivial - Clippy would like to suggest them, but had to do extra work to disable that path <https://github.com/rust-lang/rust-clippy/issues/3807> because they're unstable - These work on `PartialOrd`, consistently with now-stable `contains`, and are thus more general than iterator-based approaches that need `Step` - They've been unchanged for some time, and have picked up uses in the compiler - Stabilizing them doesn't block any future iterator-based is_empty plans, as the inherent ones are preferred in name resolution
2020-08-24Auto merge of #75876 - matklad:rust-analyzer-2020-08-24, r=matkladbors-42/+22
:arrow_up: rust-analyzer r? @ghost
2020-08-24Introduce expect snapshot testing library into rustcAleksey Kladov-0/+56
Snapshot testing is a technique for writing maintainable unit tests. Unlike usual `assert_eq!` tests, snapshot tests allow to *automatically* upgrade expected values on test failure. In a sense, snapshot tests are inline-version of our beloved UI-tests. Example: ![expect](https://user-images.githubusercontent.com/1711539/90888810-3bcc8180-e3b7-11ea-9626-d06e89e1a0bb.gif) A particular library we use, `expect_test` provides an `expect!` macro, which creates a sort of self-updating string literal (by using `file!` macro). Self-update is triggered by setting `UPDATE_EXPECT` environmental variable (this info is printed during the test failure). This library was extracted from rust-analyzer, where we use it for most of our tests. There are some other, more popular snapshot testing libraries: * https://github.com/mitsuhiko/insta * https://github.com/aaronabramov/k9 The main differences of `expect` are: * first-class snapshot objects (so, tests can be written as functions, rather than as macros) * focus on inline-snapshots (but file snapshots are also supported) * restricted feature set (only `assert_eq` and `assert_debug_eq`) * no extra runtime (ie, no `cargo insta`) See https://github.com/rust-analyzer/rust-analyzer/pull/5101 for a an extended comparison. It is unclear if this testing style will stick with rustc in the long run. At the moment, rustc is mainly tested via integrated UI tests. But in the library-ified world, unit-tests will become somewhat more important (that's why use use `rustc_lexer` library-ified library as an example in this PR). Given that the cost of removal shouldn't be too high, it probably makes sense to just see if this flies!
2020-08-24:arrow_up: rust-analyzerAleksey Kladov-42/+22
2020-08-24Auto merge of #74590 - jyn514:timing, r=Mark-Simulacrumbors-186/+216
Add some timing info to rustdoc There are various improvements, but the main one is to time each pass that rustdoc performs (`rustdoc::passes`). Before, these were the top five timings for `cargo doc` on the cargo repository: ``` +---------------------------------+-----------+-----------------+----------+------------+ | Item | Self time | % of total time | Time | Item count | +---------------------------------+-----------+-----------------+----------+------------+ | <unknown> | 854.70ms | 20.888 | 2.47s | 744823 | +---------------------------------+-----------+-----------------+----------+------------+ | expand_crate | 795.29ms | 19.436 | 848.00ms | 1 | +---------------------------------+-----------+-----------------+----------+------------+ | metadata_decode_entry | 256.73ms | 6.274 | 279.49ms | 518344 | +---------------------------------+-----------+-----------------+----------+------------+ | resolve_crate | 240.56ms | 5.879 | 242.86ms | 1 | +---------------------------------+-----------+-----------------+----------+------------+ | hir_lowering | 146.79ms | 3.587 | 146.79ms | 1 | +---------------------------------+-----------+-----------------+----------+------------+ ``` Now the timings are: ``` +---------------------------------+-----------+-----------------+----------+------------+ | Item | Self time | % of total time | Time | Item count | +---------------------------------+-----------+-----------------+----------+------------+ | <unknown> | 1.40s | 22.662 | 3.73s | 771430 | +---------------------------------+-----------+-----------------+----------+------------+ | collect-trait-impls | 1.34s | 21.672 | 2.87s | 1 | +---------------------------------+-----------+-----------------+----------+------------+ | expand_crate | 1.21s | 19.577 | 1.28s | 1 | +---------------------------------+-----------+-----------------+----------+------------+ | build extern trait impl | 704.66ms | 11.427 | 1.07s | 21893 | +---------------------------------+-----------+-----------------+----------+------------+ | metadata_decode_entry | 354.84ms | 5.754 | 391.81ms | 544919 | +---------------------------------+-----------+-----------------+----------+------------+ ``` The goal is to help me debug regressions like https://github.com/rust-lang/rust/pull/74518#issuecomment-661498214 (currently I have _no_ idea what could have gone wrong). r? @eddyb or @Mark-Simulacrum
2020-08-24hir: consistent use and naming of lang itemsDavid Wood-299/+277
This commit adjusts the naming of various lang items so that they are consistent and don't include prefixes containing the target or "LangItem". In addition, lang item variants are no longer exported from the `lang_items` module. Signed-off-by: David Wood <david@davidtw.co>
2020-08-24Auto merge of #75815 - jyn514:ambiguous-primitives, r=guillaumegomezbors-59/+203
Report an ambiguity if both modules and primitives are in scope for intra-doc links Closes https://github.com/rust-lang/rust/issues/75381 - Add a new `prim@` disambiguator, since both modules and primitives are in the same namespace - Refactor `report_ambiguity` into a closure Additionally, I noticed that rustdoc would previously allow `[struct@char]` if `char` resolved to a primitive (not if it had a DefId). I fixed that and added a test case. I also need to update libstd to use `prim@char` instead of `type@char`. If possible I would also like to refactor `ambiguity_error` to use `Disambiguator` instead of its own hand-rolled match - that ran into issues with `prim@` (I updated one and not the other) and it would be better for them to be in sync.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-05 21:09:58 +0000