| Age | Commit message (Collapse) | Author | Lines |
|---|
|
1.6 release notes for beta branch
|
|
|
|
|
|
Bump prerelease to .4
|
|
|
|
Beta next
|
|
|
|
Closes #30156.
|
|
Beta next
|
|
|
|
cc #30346
Conflicts:
src/librustc_lint/lib.rs
|
|
This feature is partially stabilized, so describe each part in the appropriate place.
Conflicts:
src/doc/book/no-stdlib.md
|
|
[beta] Fix rustdoc reexports.
|
|
|
|
Bump prerelease version to .2
|
|
|
|
More beta ports
|
|
Previously passed --cfg was used only when collecting doctests.
|
|
Checks for a `10.` prefix on the subfolder
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
Fixes https://github.com/rust-lang/rust/issues/30229
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
[beta] Add test for "malformed macro lhs" and change back span_bug to span_f…
|
|
|
|
Beta backport of #30293
|
|
|
|
|
|
[beta] Backport fix for issue 29857
|
|
pnkfelix/pr30753-betaport-downgrade-struct-warn-to-err
[beta] downgrade struct warn to err
|
|
exit.
I think that behavior is fine, so I am removing the expected warnings from these tests.
|
|
|
|
|
|
(this makes them handled like enum unit-variants.)
|
|
|
|
an error) but the bugfix causes this warning to propagate and become an
unresolved variable instead of a `TyError`, so we wind up seeing an
obscure inference error afterwards, which is somewhat unfortunate,
and suggests this bugfix can cause RFC 1214 warnings to become
errors.
|
|
|
|
|
|
Conflicts:
src/test/compile-fail/issue-3973.rs
|
|
the problem is that now "type_is_known_to_be_sized" now returns
false when called on a type with ty_err inside - this prevents
spurious errors (we may want to move the check to check::cast
anyway - see #12894).
|
|
of `TyError`
Conflicts:
src/test/compile-fail/issue-29857.rs
|
|
r? @eefriedman
It was getting out of hand with my additions to the const evaluator
|
|
r=alexcrichton
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.
This is another path to resolving #30063 for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
r? @alexcrichton
|
|
None
|
|
- Successful merges: #30201, #30224, #30261, #30273, #30274
- Failed merges:
|
|
|
|
Changes to readability and some clarifications for beginners
|
|
see https://github.com/rust-lang/rust/pull/30202/files#r46819188
r? @pnkfelix
the only difference between the tests is that one has the const_indexing feature enabled.
|
|
Make clear that `super` may be included in the path several times.
r? @steveklabnik
|
|
r? @Manishearth
|
|
Fixes #26403
This adjusts the pointer, if needed, to the correct alignment by using the alignment information in the vtable.
Handling zero might not be necessary, as it shouldn't actually occur. I've left it as it's own commit so it can be removed fairly easily if people don't think it's worth doing. The way it's handled though means that there shouldn't be much impact on performance.
|
|
When given `rustc -C codegen-units=4 --emit=obj`, reset units back to 1.
Fix #30063
Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without `-o PATH` will "work", though it will downgrade codegen-units to 1 just like all the other cases.)
r? @alexcrichton
|
|
Instead of `ast::Ident`, bindings, paths and labels in HIR now keep a new structure called `hir::Ident` containing mtwt-renamed `name` and the original not-renamed `unhygienic_name`. `name` is supposed to be used by default, `unhygienic_name` is rarely used.
This is not ideal, but better than the status quo for two reasons:
- MTWT tables can be cleared immediately after lowering to HIR
- This is less bug-prone, because it is impossible now to forget applying `mtwt::resolve` to a name. It is still possible to use `name` instead of `unhygienic_name` by mistake, but `unhygienic_name`s are used only in few very special circumstances, so it shouldn't be a problem.
Besides name resolution `unhygienic_name` is used in some lints and debuginfo. `unhygienic_name` can be very well approximated by "reverse renaming" `token::intern(name.as_str())` or even plain string `name.as_str()`, except that it would break gensyms like `iter` in desugared `for` loops. This approximation is likely good enough for lints and debuginfo, but not for name resolution, unfortunately (see https://github.com/rust-lang/rust/issues/27639), so `unhygienic_name` has to be kept.
cc https://github.com/rust-lang/rust/issues/29782
r? @nrc
|
