about summary refs log tree commit diff
path: root/src
AgeCommit message (Collapse)AuthorLines
2020-10-11Auto merge of #75991 - shepmaster:silicon-ci, r=pietroalbinibors-6/+59
Set up CI for aarch64-apple-darwin
2020-10-11Auto merge of #76859 - Aaron1011:fix/llvm-cgu-reuse, r=davidtwco,nikicbors-2/+53
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse During incremental ThinLTO compilation, we attempt to re-use the optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do so. Up until now, 'safe' has meant that the set of modules that our current modules imports from/exports to is unchanged from the previous compilation session. See PR #67020 and PR #71131 for more details. However, this turns out be insufficient to guarantee that it's safe to reuse the post-LTO module (i.e. that optimizing the pre-LTO module would produce the same result). When LLVM optimizes a module during ThinLTO, it may look at other information from the 'module index', such as whether a (non-imported!) global variable is used. If this information changes between compilation runs, we may end up re-using an optimized module that (for example) had dead-code elimination run on a function that is now used by another module. Fortunately, LLVM implements its own ThinLTO module cache, which is used when ThinLTO is performed by a linker plugin (e.g. when clang is used to compile a C proect). Using this cache directly would require extensive refactoring of our code - but fortunately for us, LLVM provides a function that does exactly what we need. The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash from all data that might influence the result of ThinLTO on a module. In addition to the module imports/exports that we manually track, it also hashes information about global variables (e.g. their liveness) which might be used during optimization. By using this function, we shouldn't have to worry about new LLVM passes breaking our module re-use behavior. In LLVM, the output of this function forms part of the filename used to store the post-ThinLTO module. To keep our current filename structure intact, this PR just writes out the mapping 'CGU name -> Hash' to a file. To determine if a post-LTO module should be reused, we compare hashes from the previous session. This should unblock PR #75199 - by sheer chance, it seems to have hit this issue due to the particular CGU partitioning and optimization decisions that end up getting made.
2020-10-10Re-enable test caseDániel Buga-2/+1
2020-10-10Apply suggestions from code reviewDániel Buga-16/+22
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-10-10Refactor path resolution and use Symbols instead of &strDániel Buga-115/+136
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-10-10Apply suggestions from code reviewDániel Buga-16/+34
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-10-10Clean up hard to follow control flowDániel Buga-42/+45
2020-10-10Clean up check_full_resDániel Buga-22/+13
2020-10-11Auto merge of #77774 - petrochenkov:floatuple, r=estebankbors-12/+12
rustc_parse: More precise spans for `tuple.0.0` This should help with https://github.com/rust-lang/rustfmt/issues/4355, but I haven't verified, cc `@calebcartwright.`
2020-10-11Auto merge of #77649 - dash2507:replace_run_compiler, r=matthewjasperbors-10/+5
Replace run_compiler with RunCompiler builder pattern Fixes #77286. Replaces rustc_driver:run_compiler with RunCompiler builder pattern.
2020-10-11rustc_parse: More precise spans for `tuple.0.0`Vadim Petrochenkov-12/+12
2020-10-10Auto merge of #77087 - estebank:issue-45817, r=matthewjasperbors-8/+292
Provide structured suggestions when finding structs when expecting a trait When finding an ADT in a trait object definition provide some solutions. Fix #45817. Given `<Param as Trait>::Assoc: Ty` suggest `Param: Trait<Assoc = Ty>`. Fix #75829.
2020-10-10Auto merge of #76934 - camelid:rustdoc-allow-generic-params, r=jyn514bors-15/+427
Allow generic parameters in intra-doc links Fixes #62834. --- The contents of the generics will be mostly ignored (except for warning if fully-qualified syntax is used, which is currently unsupported in intra-doc links - see issue #74563). * Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>` * Allow links like `Vec::<T>::new()` * Warn on * Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`) * Missing type to apply generics to (`<T>` or `<Box<T>>`) * Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`) * Invalid path separator (`Vec:<T>:new`) * Too many angle brackets (`Vec<<T>>`) * Empty angle brackets (`Vec<>`) Note that this implementation *does* allow some constructs that aren't valid in the actual Rust syntax, for example `Box::<T>new()`. That may not be supported in rustdoc in the future; it is an implementation detail.
2020-10-10Auto merge of #77798 - JohnTitor:rollup-82u711m, r=JohnTitorbors-10/+6
Rollup of 10 pull requests Successful merges: - #77195 (Link to documentation-specific guidelines.) - #77629 (Cleanup of `eat_while()` in lexer) - #77709 (Link Vec leak doc to Box) - #77738 (fix __rust_alloc_error_handler comment) - #77748 (Dead code cleanup in windows-gnu std) - #77754 (Add TraitDef::find_map_relevant_impl) - #77766 (Clarify the debug-related values should take boolean) - #77777 (doc: disambiguate stat in MetadataExt::as_raw_stat) - #77782 (Fix typo in error code description) - #77787 (Update `changelog-seen` in config.toml.example) Failed merges: r? `@ghost`
2020-10-11Rollup merge of #77754 - bugadani:find_map_relevant_impl, r=matthewjasperYuki Okushi-10/+6
Add TraitDef::find_map_relevant_impl This PR adds a method to `TraitDef`. While `for_each_relevant_impl` covers the general use case, sometimes it's not necessary to scan through all the relevant implementations, so this PR introduces a new method, `find_map_relevant_impl`. I've also replaced the `for_each_relevant_impl` calls where possible. I'm hoping for a tiny bit of efficiency gain here and there.
2020-10-10Auto merge of #77337 - lzutao:asm-mips64, r=Amanieubors-68/+113
Add asm! support for mips64 - [x] Updated `src/doc/unstable-book/src/library-features/asm.md`. - [ ] No vector type support. I don't know much about those types. cc #76839
2020-10-10Auto merge of #77771 - nagisa:revert-77023, r=Mark-Simulacrumbors-24/+0
Revert "Assume slice len is bounded by allocation size" https://github.com/rust-lang/rust/pull/77023#issuecomment-703987379 suggests that the original PR introduced a significant perf regression. This reverts commit e44784b8750016a695361c990024750e037d8f9f / #77023. cc `@HeroicKatora`
2020-10-10Auto merge of #77336 - pietroalbini:pkgname, r=Mark-Simulacrumbors-111/+11
Always use the Rust version in package names The format of the tarballs produced by CI is roughly the following: {component}-{release}-{target}.{ext} While on the beta and nightly channels `{release}` is just the channel name, on the stable channel is either the Rust version or the version of the component we're shipping: cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz ... This makes it really hard to get the package URL without having access to the manifest (and there is no manifest on ci-artifacts.rlo), as there is no consistent version number to use. This PR addresses the problem by always using the Rust version number as `{release}` for the stable channel, regardless of the version number of the component we're shipping. I chose that instead of "stable" to avoid breaking the URL scheme *that* much. Rustup should not be affected by this change, as it fetches the URLs from the manifest. Unfortunately we don't have a way to test other clients before making a stable release, as this change only affects the stable channel. r? `@Mark-Simulacrum`
2020-10-09address review commentsEsteban Küber-1/+71
2020-10-09Move `@has` checks closer to corresponding doc commentsCamelid-15/+19
2020-10-09Use `next()` instead of `peek()` where possibleCamelid-3/+3
2020-10-09Link to GitHub issue re macro resolutionCamelid-1/+3
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-10-10Revert "Assume slice len is bounded by allocation size"Simonas Kazlauskas-24/+0
https://github.com/rust-lang/rust/pull/77023#issuecomment-703987379 suggests that the original PR introduced a significant perf regression. This reverts commit e44784b8750016a695361c990024750e037d8f9f / #77023.
2020-10-09Given `<T as Trait>::A: Ty` suggest `T: Trait<A = Ty>`Esteban Küber-0/+32
Fix #75829
2020-10-09Suggest removing bounds even when potential typoEsteban Küber-1/+17
2020-10-09Tweak output and add test casesEsteban Küber-11/+171
2020-10-09Point out why a trait is expected on `Struct + 'lt`Esteban Küber-0/+6
2020-10-09Auto merge of #77276 - GuillaumeGomez:reexported-item-lints, r=jyn514,ollie27bors-19/+95
Warn on broken intra-doc links added to cross-crate re-exports This emits `broken_intra_doc_links` for docs applied to pub use statements that point to external items and are inlined. Does not address #77200 - any existing broken links from the original crate will not show warnings. r? `@jyn514`
2020-10-09Don't filter out imports added by the compiler for the momentGuillaume Gomez-6/+0
2020-10-09Remove unneeded ImportItem on glob onesGuillaume Gomez-26/+3
2020-10-09Simplify included import items handlingGuillaume Gomez-41/+55
2020-10-09Add test to ensure that external items aren't lint-checkedGuillaume Gomez-4/+16
2020-10-09Correctly handle "pub use" reexportsGuillaume Gomez-13/+32
2020-10-09Add test for reexported items lintsGuillaume Gomez-0/+31
2020-10-09Don't remove export items so that we can run lints on themGuillaume Gomez-3/+32
2020-10-09Auto merge of #77747 - flip1995:clippyup, r=Manishearthbors-616/+1502
Update Clippy Biweekly Clippy update. This includes a `Cargo.lock` update: 7ea42be r? `@Manishearth`
2020-10-09Auto merge of #77609 - ortem:fix-lldb-commands, r=Mark-Simulacrumbors-17/+17
Remove redundant backslashes from `lldb_commands`
2020-10-09Add find_map_relevant_implDániel Buga-10/+6
2020-10-09bootstrap: always use the Rust version in package namesPietro Albini-111/+11
The format of the tarballs produced by CI is roughly the following: {component}-{release}-{target}.{ext} While on the beta and nightly channels `{release}` is just the channel name, on the stable channel is either the Rust version or the version of the component we're shipping: cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz ... This makes it really hard to get the package URL without having access to the manifest (and there is no manifest on ci-artifacts.rlo), as there is no consistent version number to use. This commit addresses the problem by always using the Rust version number as `{release}` for the stable channel, regardless of the version number of the component we're shipping. I chose that instead of "stable" to avoid breaking the URL scheme *that* much. Rustup should not be affected by this change, as it fetches the URLs from the manifest. Unfortunately we don't have a way to test other clients before making a stable release, as this change only affects the stable channel.
2020-10-09Merge commit '2f6439ae6a6803d030cceb3ee14c9150e91b328b' into clippyupflip1995-616/+1502
2020-10-09Auto merge of #77627 - richkadel:rust-demangler, r=tmandrybors-4/+62
rust-demangler tool strips crate disambiguators with < 16 digits Addresses Issue #77615.
2020-10-08Update rustdoc intra-doc link docsCamelid-13/+40
* Describe generic parameters feature * Make general improvements to the docs
2020-10-08Allow generic parameters in intra-doc linksCamelid-2/+381
The contents of the generics will be mostly ignored (except for warning if fully-qualified syntax is used, which is currently unsupported in intra-doc links - see issue #74563). * Allow links like `Vec<T>`, `Result<T, E>`, and `Option<Box<T>>` * Allow links like `Vec::<T>::new()` * Warn on * Unbalanced angle brackets (e.g. `Vec<T` or `Vec<T>>`) * Missing type to apply generics to (`<T>` or `<Box<T>>`) * Use of fully-qualified syntax (`<Vec as IntoIterator>::into_iter`) * Invalid path separator (`Vec:<T>:new`) * Too many angle brackets (`Vec<<T>>`) * Empty angle brackets (`Vec<>`) Note that this implementation *does* allow some constructs that aren't valid in the actual Rust syntax, for example `Box::<T>new()`. That may not be supported in rustdoc in the future; it is an implementation detail.
2020-10-09Auto merge of #77578 - euclio:max-suggestion, r=davidtwcobors-1/+45
suggest `MAX` constant if -1 is assigned to unsigned type Fixes #76413. Fixes #77416.
2020-10-09Auto merge of #77519 - jyn514:track-doc-er, r=GuillaumeGomezbors-112/+235
Resolve intra-doc links on additional documentation for re-exports in lexical scope Fixes https://github.com/rust-lang/rust/issues/77254. - Preserve the parent module of `DocFragment`s + Add `parent_module` to `DocFragment` + Require the `parent_module` of the item being inlined + Preserve the hir_id for ExternCrates so rustdoc can find the parent module later + Take an optional `parent_module` for `build_impl` and `merge_attrs`. Preserve the difference between parent modules for each doc-comment. + Support a single additional re-exports in from_ast. Originally this took a vec but I ended up not using it. + Don't require the parent_module for all `impl`s, just inlined items In particular, this will be `None` whenever the attribute is not on a re-export. + Only store the parent_module, not the HirId When re-exporting a re-export, the HirId is not available. Fortunately, `collect_intra_doc_links` doesn't actually need all the info from a HirId, just the parent module. - Introduce `Divider` This distinguishes between documentation on the original from docs on the re-export. - Use the new module information for intra-doc links + Make the parent module conditional on whether the docs are on a re-export + Make `resolve_link` take `&Item` instead of `&mut Item` Previously the borrow checker gave an error about multiple mutable borrows, because `dox` borrowed from `item`. + Fix `crate::` for re-exports `crate` means something different depending on where the attribute came from. + Make it work for `#[doc]` attributes too This required combining several attributes as one so they would keep the links. r? `@GuillaumeGomez`
2020-10-09Auto merge of #76260 - xd009642:rfc/2867, r=jonas-schievinkbors-0/+63
Implementation of RFC2867 https://github.com/rust-lang/rust/issues/74727 So I've started work on this, I think my next steps are to make use of the `instruction_set` value in the llvm codegen but this is the point where I begin to get a bit lost. I'm looking at the code but it would be nice to have some guidance on what I've currently done and what I'm doing next :smile:
2020-10-08Fix typo in error codexd009642-1/+1
2020-10-08Auto merge of #77723 - jonas-schievink:rollup-htz44r4, r=jonas-schievinkbors-0/+19
Rollup of 8 pull requests Successful merges: - #76750 (Don't discourage implementing `core::fmt::Write`) - #77449 (BTreeMap: comment why drain_filter's size_hint is somewhat pessimistic) - #77660 ((docs): make mutex error comment consistent with codebase) - #77663 (Add compile fail test for issue 27675) - #77673 (Remove unnecessary lamda on emitter map.) - #77701 (Make `max_log_info` easily greppable (for figuring out why debug logging is disabled)) - #77702 (Remove not needed lambda.) - #77710 (Update submodule llvm to get LVI bugfix) Failed merges: r? `@ghost`
2020-10-08Implement the instruction_set attributexd009642-0/+63
2020-10-08Auto merge of #6117 - dtolnay:string_lit_as_bytes, r=ebrotobors-1/+1
Downgrade string_lit_as_bytes to nursery Between #1402 (regarding `to_owned`) and #4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default. I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error. As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned. --- changelog: Remove string_lit_as_bytes from default set of enabled lints
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-24 05:25:51 +0000