| Age | Commit message (Collapse) | Author | Lines |
|
`PointerKind` is included in `LoanPath` and hence forms part of the
equality check; this led to having two unequal paths that both
represent `*x`, depending on whether the `*` was inserted
automatically or explicitly. Bad mojo. The `note` field, in contrast,
is intended more-or-less primarily for this purpose of adding extra
data.
|
|
This fixes the regression in #49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.
closes #49934
|
|
|
|
|
|
the same enum
|
|
[beta] Another round of backports
This is a backport of:
* https://github.com/rust-lang/rust/pull/50039
* https://github.com/rust-lang/rust/pull/50121
|
|
|
|
`()`, not `!`.
Note that this commit, since it is trying to be minimal in order to
ease backporting to the beta and release channels, does *not* include
the old future-proofing warnings that we used to have associated with
such fallback to `()`; see discussion at this comment:
https://github.com/rust-lang/rust/issues/49691#issuecomment-381266730
|
|
This commit is just covering the feature gate itself and the tests
that made direct use of `!` and thus need to opt back into the
feature.
A follow on commit brings back the other change that motivates the
revert: Namely, going back to the old rules for falling back to `()`.
|
|
This commit papers over #49889 (introducing a fixme pointing at #50125) for a
bug that was introduced with #49695. This workaround is taken from #49891.
|
|
|
|
|
|
|
|
|
|
In intercrate mode, if we determine that a particular `T: Trait` is
unknowable, we sometimes also go and get extra causal information. An
errant `?` was causing us to propagate an error found in that process
out as if `T: Trait` was not unknowable but rather not provable. This
led to an ICE.
|
|
Fixes #49631
|
|
|
|
Backport of #49904
See #49904.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rename fs::read_string to read_to_string and stabilize
As approved in https://github.com/rust-lang/rust/issues/46588#issuecomment-377530365
Closes #46588.
|
|
Implement some trivial size_hints for various iterators
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
I intend to do more, but I don't want to make the PR too large.
|
|
|
|
Fix stable hashing of AllocIds
r? @michaelwoerister
fixes #49081
|
|
Remove universes from `ty::ParamEnv`
This change was never meant to land. #48407 takes an alternate approach. However, that PR is now blocked on some issues with canonicalization, and rebasing these reverts gets harder each time, so let's just get this bit out of the way now.
r? @nikomatsakis
|
|
r=petrochenkov
Check for known but incorrect attributes
fixes #43988
- Change nested_visit_map so it will recursively check functions
- Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
- Add regression test for issue #43988
|
|
|
|
Stabilize match_default_bindings
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
r? @nikomatsakis
cc https://github.com/rust-lang/rust/issues/42640
Many of the tests this PR touches are merely testing the current lack of desired future behavior around https://github.com/rust-lang/rust/issues/44849 and https://github.com/rust-lang/rust/issues/44848 (cc @tschottdorf). I noticed the bullets for those items were checked on the tracking issue-- I've unchecked them, as they don't appear to have been completed and I don't see any comments indicating that we don't want to pursue them further. Still, I think it's fine to stabilize the current behavior, as I think expanding it in the future should be backwards-compatible.
|
|
Introduce a TargetTriple enum to support absolute target paths
This PR replaces target triple strings with a `TargetTriple` enum, which represents either a target triple or a path to a JSON target file. The path variant is used if the `--target` argument has a `.json` extension, else the target triple variant is used.
The motivation of this PR is support for absolute target paths to avoid the need for setting the `RUST_TARGET_PATH` environment variable (see rust-lang/cargo#4905 for more information). For places where some kind of triple is needed (e.g. in the sysroot folder), we use the file name (without extension).
For compatibility, we keep the old behavior of searching for a file named `$(target_triple).json` in `RUST_TARGET_PATH` for non-official target triples.
|
|
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
|
|
|
|
Allow niche-filling dataful variants to be represented as a ScalarPair
r? @eddyb
|
|
Update CONTRIBUTING.md
The current link is a 404, just link to the main repo page
|
|
|
|
Introduce trait engine
address #48895 step 1: introduce trait engine
|
|
Fix pretty-printing for raw identifiers
|
|
|
|
rustbuild: Fail the build if we build Cargo twice
This commit updates the `ToolBuild` step to stream Cargo's JSON messages, parse
them, and record all libraries built. If we build anything twice (aka Cargo)
it'll most likely happen due to dependencies being recompiled which is caught by
this check.
|
|
|
|
This commit updates the `ToolBuild` step to stream Cargo's JSON messages, parse
them, and record all libraries built. If we build anything twice (aka Cargo)
it'll most likely happen due to dependencies being recompiled which is caught by
this check.
|
|
Stabilize 128-bit integers :tada:
cc #35118
EDIT: This should be merged only after the following have been merged:
- [x] https://github.com/rust-lang-nursery/compiler-builtins/pull/236
- [x] https://github.com/rust-lang/book/pull/1230
|
|
|
|
|
|
- Change nested_visit_map so it will recusively check functions
- Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
- Add regression test for isssue #43988
|
|
|
|
|