about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2021-09-28Merge remote-tracking branch 'upstream/master' into rustupflip1995-908/+1979
2021-09-28Auto merge of #89293 - ↵bors-1/+52
TaKO8Ki:fix-confusing-error-for-path-separator-to-refer-to-an-struct-item, r=estebank Suggest using the path separator for tuple struct Fix confusing error message `constructor is not visible here due to private fields` for tuple struct closes #83450
2021-09-28rustc_session: Remove lint store from `Session`Vadim Petrochenkov-37/+4
2021-09-28Auto merge of #89277 - jyn514:codeblock-edition, r=GuillaumeGomezbors-19/+60
Use the correct edition for syntax highlighting doctests Previously it would unconditionally use edition 2015, which was incorrect. Helps with https://github.com/rust-lang/rust/issues/89135 in that you can now override the doctest to be 2018 edition instead of being forced to fix the error. This doesn't resolve any of the deeper problems that rustdoc disagrees with most rust users on what a code block is. cc `@Mark-Simulacrum`
2021-09-28Auto merge of #7608 - andrewpollack:7594/while_let_some_result, r=Manishearthbors-87/+186
#7594: Adding new 'while_let_some_result' linting Excited for the opportunity to contribute to Clippy! Since the latest Bay Area Rust Meetup, I've been looking for an opportunity and found it :smile: Please let me know how I can improve this PR! Much of it is similar to ``[`if_let_some_result`]``, but I followed the description in the issue to create its own linting rules. Looking forward to feedback, and continuing to work on Clippy in the future! changelog: Renamed Lint: `if_let_some_result` is now called [`match_result_ok`]. Now also handles `while let` case.
2021-09-27fmtManish Goregaokar-7/+8
2021-09-27Add renamed lintManish Goregaokar-0/+1
2021-09-27Use a single if_chainManish Goregaokar-31/+9
2021-09-27Adjusting changelogAndrew Pollack-1/+1
2021-09-27Removed value from changelog to get passAndrew Pollack-1/+1
2021-09-27Adding new lintingAndrew Pollack-142/+261
2021-09-28Add SOLID targetsTomoaki Kawada-0/+4062
SOLID[1] is an embedded development platform provided by Kyoto Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support for SOLID. # New Targets The following targets are added: - `aarch64-kmc-solid_asp3` - `armv7a-kmc-solid_asp3-eabi` - `armv7a-kmc-solid_asp3-eabihf` SOLID's target software system can be divided into two parts: an RTOS kernel, which is responsible for threading and synchronization, and Core Services, which provides filesystems, networking, and other things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems (more precisely, systems where only one processor core is allocated for SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is traditionally only specified at the source-code level, the ABI is unique to each implementation, which is why `asp3` is included in the target names. More targets could be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future. # C Compiler Although SOLID provides its own supported C/C++ build toolchain, GNU Arm Embedded Toolchain seems to work for the purpose of building Rust. # Unresolved Questions A μITRON4 kernel can support `Thread::unpark` natively, but it's not used by this commit's implementation because the underlying kernel feature is also used to implement `Condvar`, and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives. # Unsupported or Unimplemented Features Most features are implemented. The following features are not implemented due to the lack of native support: - `fs::File::{file_attr, truncate, duplicate, set_permissions}` - `fs::{symlink, link, canonicalize}` - Process creation - Command-line arguments Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however. ## Dynamic Linking Dynamic linking is not supported. The target platform supports dynamic linking, but enabling this in Rust causes several problems. - The linker invocation used to build the shared object of `std` is too long for the platform-provided linker to handle. - A linker script with specific requirements is required for the compiled shared object to be actually loadable. As such, we decided to disable dynamic linking for now. Regardless, the users can try to create shared objects by manually invoking the linker. ## Executable Building an executable is not supported as the notion of "executable files" isn't well-defined for these targets. [1] https://solid.kmckk.com/SOLID/ [2] http://ertl.jp/ITRON/SPEC/mitron4-e.html [3] https://en.wikipedia.org/wiki/ITRON_project [4] https://toppers.jp/
2021-09-28Clarify that `CString::from_vec_unchecked` appends 0 byte.et342-0/+2
2021-09-27Fix/count trailing zeroes (#95)antoyo-162/+216
* Fix count trailing zeroes * Fix pop count * Fix bit reverse
2021-09-28print-type-sizes: skip field printing for primitivesTomasz Miąsko-3/+7
2021-09-28Add unit assignment to MIR for `asm!()`Fabian Wolff-3/+35
2021-09-27Fix/mismatch types (#94)antoyo-74/+132
* Refactor test.sh script * Fix mismatched types error
2021-09-27PassWrapper: handle function rename from upstream D36850Augie Fackler-0/+4
thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and gained the ability to propagate noRecurse and noUnwind function attributes. I ran codegen tests with it both on and off, as the upstream patch uses it in both modes, and the tests pass both ways. Given that, it seemed reasonable to go ahead and let the propagation be enabled in rustc, and see what happens. See https://reviews.llvm.org/D36850 for more examples of how the new version of the function gets used.
2021-09-27Apply suggestions from code reviewJane Lusby-2/+2
Co-authored-by: kennytm <kennytm@gmail.com>
2021-09-27Auto merge of #89249 - Aaron1011:higher-ranked-cause, r=estebankbors-86/+209
Improve cause information for NLL higher-ranked errors This PR has several interconnected pieces: 1. In some of the NLL region error code, we now pass around an `ObligationCause`, instead of just a plain `Span`. This gets forwarded into `fulfill_cx.register_predicate_obligation` during error reporting. 2. The general InferCtxt error reporting code is extended to handle `ObligationCauseCode::BindingObligation` 3. A new enum variant `ConstraintCategory::Predicate` is added. We try to avoid using this as the 'best blame constraint' - instead, we use it to enhance the `ObligationCause` of the `BlameConstraint` that we do end up choosing. As a result, several NLL error messages now contain the same "the lifetime requirement is introduced here" message as non-NLL errors. Having an `ObligationCause` available will likely prove useful for future improvements to NLL error messages.
2021-09-27Auto merge of #89214 - smoelius:register_tool, r=petrochenkovbors-6/+43
Pass real crate-level attributes to `pre_expansion_lint` The PR concerns the unstable feature `register_tool` (#66079). The feature's implementation requires the attributes of the crate being compiled, so that when attributes like `allow(foo::bar)` are encountered, it can be verified that `register_tool(foo)` appears in the crate root. However, the crate's attributes are not readily available during early lint passes. Specifically, on this line, `krate.attrs` appears to be the attributes of the current source file, not the attributes of the whole crate: https://github.com/rust-lang/rust/blob/bf642323d621dcefeef1d8ab4711aae36e357615/compiler/rustc_lint/src/context.rs#L815 Consequently, "unknown tool" errors were being produced when `allow(foo::bar)` appeared in a submodule, even though `register_tool(foo)` appeared in the crate root. EDITED: The proposed fix is to obtain the real crate-level attributes in `configure_and_expand` and pass them to `pre_expansion_lint`. (See `@petrochenkov's` [comment](https://github.com/rust-lang/rust/pull/89214#issuecomment-926927072) below.) The original "prosed fix" text follows. --- The proposed fix is to add an `error_on_unknown_tool` flag to `LintLevelsBuilder`. The flag controls whether "unknown tool" errors are emitted. The flag is set during late passes, but not earlier. More specifically, this PR contains two commits: * The first adds a `known-tool-in-submodule` UI test that does not currently pass. * The second adds the `error_on_unknown_tool` flag. The new test passes with the addition of this flag. This change has the added benefit of eliminating some errors that were duplicated in existing tests. To the reviewer: please check that I implemented the UI test correctly.
2021-09-27thread: implements available_concurrency on haikuDavid Carlier-1/+10
2021-09-27#[feature] not required for lint resultGus Wynn-5/+4
2021-09-27Remove `DefId` from `ConstraintCategory::Predicate`Aaron Hill-9/+20
This shirnks the size of `ConstraintCategory`, hopefully fixing a performance regression.
2021-09-27lock typesGus Wynn-0/+58
2021-09-27Improve cause information for NLL higher-ranked errorsAaron Hill-85/+197
This PR has several interconnected pieces: 1. In some of the NLL region error code, we now pass around an `ObligationCause`, instead of just a plain `Span`. This gets forwarded into `fulfill_cx.register_predicate_obligation` during error reporting. 2. The general InferCtxt error reporting code is extended to handle `ObligationCauseCode::BindingObligation` 3. A new enum variant `ConstraintCategory::Predicate` is added. We try to avoid using this as the 'best blame constraint' - instead, we use it to enhance the `ObligationCause` of the `BlameConstraint` that we do end up choosing. As a result, several NLL error messages now contain the same "the lifetime requirement is introduced here" message as non-NLL errors. Having an `ObligationCause` available will likely prove useful for future improvements to NLL error messages.
2021-09-27Auto merge of #89285 - jackh726:issue-88862, r=nikomatsakisbors-8/+8
Don't normalize opaque types with escaping late-bound regions Fixes #88862 Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf. Needs a perf run once https://github.com/rust-lang/rustc-perf/pull/1033 is merged r? `@nikomatsakis`
2021-09-27Cleanup fix for global initialization (#93)antoyo-15/+5
* Cleanup fix for global initialization * Remove linker script hack * Use v0 symbol mangling * Fix warnings
2021-09-27Update issue-89193.rsGeorge O'Hara-4/+2
2021-09-27Issue 89193George O'Hara-8/+78
2021-09-27Auto merge of #89263 - ↵bors-92/+211
TaKO8Ki:suggest-both-immutable-and-mutable-trait-implementations, r=estebank Suggest both of immutable and mutable trait implementations closes #85865
2021-09-27Update changelog to 1.56flip1995-3/+71
2021-09-27Auto merge of #7664 - matthiaskrgr:bump_to_2021, r=flip1995bors-6/+6
bump clippy crates to edition 2021 Also helps with dogfooding edition 2021 a bit. :) Tests passed locally. --- changelog: bump edition from 2018 to 2021
2021-09-27Auto merge of #7692 - workingjubilee:float-cmp-not-wrong, r=giraffatebors-3/+2
Demote float_cmp to pedantic See this issue: https://github.com/rust-lang/rust-clippy/issues/7666 This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them. A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons. changelog: Demote [`float_cmp`] from correctness to pedantic lints
2021-09-27Auto merge of #89203 - GuillaumeGomez:cleanup-rustdoc-types, r=camelidbors-42/+40
Clean up clean/types.rs file by making the implementations follow the type declaration This PR doesn't change anything, it simply moves things around: when reading the code, I realized a few times that a type declaration and implementations on it might be separated by some other type declarations, which makes the reading much more complicated. I put back impl and declaration together. r? `@camelid`
2021-09-27:arrow_up: rust-analyzerLaurențiu Nicola-16/+17
2021-09-27suggest path for tuple structTakayuki Maeda-1/+52
2021-09-27Auto merge of #89182 - GuillaumeGomez:boostrap-explicit-request, ↵bors-17/+30
r=Mark-Simulacrum Simplify explicit request check and allow to run "doc src/librustdoc" even without config set Originally I wanted to allow the command `doc src/librustdoc` to work when passed explicitly but then `@Mark-Simulacrum` recommended me to generalize it, so here we are! r? `@Mark-Simulacrum`
2021-09-26Link stage1 build to toolchain automaticallyTimothy Maloney-0/+80
Fixed types Add checks for rustup and if toolchain is linked Fortified rustup/directory checks; made other suggested changes Added check for output status Remove output of rustup from console Made suggested change Deleted confusing comment Fixed compiler error; removed extra declaration Refactored to smaller components; made suggested changes Automate toolchain linking for stage 1 builds
2021-09-27Auto merge of #89145 - rusticstuff:bump_stdarch, r=kennytmbors-0/+0
Update stdarch submodule This is mainly to fix the critical issue of aarch64 store intrinsics overwriting additional memory, see https://github.com/rust-lang/stdarch/issues/1220 Changes: * aarch64/armv7: additional vld1/vst1 intrinsics + perf fixes for existing ones * https://github.com/rust-lang/stdarch/pull/1205 * https://github.com/rust-lang/stdarch/pull/1207 * https://github.com/rust-lang/stdarch/pull/1216 * armv7: Make FMA work with vfpv4 and optimize * https://github.com/rust-lang/stdarch/pull/1219 * Non-visible changes to the testing framework * https://github.com/rust-lang/stdarch/pull/1208 * https://github.com/rust-lang/stdarch/pull/1211 * https://github.com/rust-lang/stdarch/pull/1213 * https://github.com/rust-lang/stdarch/pull/1215 * https://github.com/rust-lang/stdarch/pull/1218
2021-09-26Fix testRoxane-9/+5
2021-09-27Auto merge of #7722 - dtolnay-contrib:float, r=giraffatebors-37/+7
Stop suggesting a float truncation that is not shorter Fixes #7721. Previously Clippy would say that a number has excessive precision even if it has the minimum possible precision for the floating point value that it corresponds to. changelog: Fix [`excessive_precision`] being triggered on floats that are already written in shortest form
2021-09-26Auto merge of #89092 - bjorn3:sync_cg_clif-2021-09-19, r=bjorn3bors-293/+332
Sync rustc_codegen_cranelift Nothing exciting this time. Mostly internal refactorings. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
2021-09-26Pass real crate-level attributes to `pre_expansion_lint`Samuel Moelius-6/+29
2021-09-26Don't normalize opaque types with escaping late-bound regions.jackh726-8/+8
Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf.
2021-09-262229: Consume IfLet exprRoxane-0/+42
2021-09-26Add regression test for issue #83564Noah Lev-0/+26
2021-09-26Auto merge of #89144 - sexxi-goose:insig_stdlib, r=nikomatsakisbors-545/+306
2229: Mark insignificant dtor in stdlib I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop. Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501 One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion. r? `@Mark-Simulacrum` cc `@nikomatsakis`
2021-09-26Improve diagnostics for inaccessible itemsFabian Wolff-56/+164
2021-09-26Detect when negative literal indices are used and suggest appropriate codeEsteban Kuber-2/+132
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 16:57:25 +0000