jiebi/CodeConvo huggingface dataset:
Change:
/// fn b<T>() -> Foo<T, u32> { .. } /// ``` /// <del> fn find_opaque_ty_constraints(tcx: TyCtxt<'_>, def_id: LocalDefId) -> Ty<'_> { </del> <ins> fn find_opaque_ty_constraints_for_tait(tcx: TyCtxt<'_>, def_id: LocalDefId) -> Ty<'_> { </ins> use rustc_hir::{Expr, ImplItem, Item, TraitItem}; struct ConstraintLocator<'tcx> {

Discussion:
Messing around with a Haskell-like implementation of , I encountered two presumably similar ICEs (would think they're the same, but the error messages are obviously different). The other one is . I'm pretty sure this should be an error, based on the reasoning that returns an opaque type, so, while the output of might be , it also might not (and in this case, isn't), and since only accepts s, should be an error. Note that this implementation throws the ICE even without the main method, but I'm leaving it there for contrast to the other ICE. : Same ICE on nightly: <details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in
I was able to "weaponize" this into a transmute, lol: So the issue here is that, at least in the case of RPITs, we are not checking for opaque type mismatches in closures correctly. The closure, in this example, is able to incorrectly constrain even though in the enclosing function, we define . During mir borrowck, we never check these two together, so we never report a type mismatch. I think I have a fix, though.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
.arg("--target-dir") .arg(&*target_dir.to_string_lossy()) .arg("-Zskip-rustdoc-fingerprint") <ins> .arg("-Zrustdoc-map") .rustdocflag("--extern-html-root-url") .rustdocflag("std_detect=https://docs.rs/std_detect/latest/") .rustdocflag("--extern-html-root-takes-precedence") </ins> .rustdocflag("--resource-suffix") .rustdocflag(&builder.version); for arg in extra_args {

Discussion:
IIRC there is a broken link checker, but somehow it doesn't catch this case: ! which is a 404 modify labels: A-docs
Also, all source links of the macros in are broken as well.
Another reexport bug. :) EDIT: so in here the problem is that the crate isn't documented on It should redirect to .
I think the right fix is to pass -Zrustdoc-map to cargo when documenting the standard library. We already do that for the compiler docs: mentoring instructions: add that same flag to .
cc , which is one way to fix this in rustdoc, but will result in a worse experience for the source view.
I just opened a PR for this issue: I confirmed that it fixes this issue. One of my concerns is that it is very similar to even if I followed the mentoring instructions. And the other concern is that although this PR fixes the main issue, there is another issue: Macros here seems still not working: Actually is working after this PR but others aren't; I think there is some mismatch about generating links between Cargo and I can investigate this second issue further in this issue or in a new issue but at first I wanna ensure that I am on the right way.
Change:
projection_ty: projection_ty, ty: ty_var }); <del> let obligation = Obligation::with_depth(cause, depth+1, projection.to_predicate()); </del> <ins> let obligation = Obligation::with_depth( cause, depth + 1, projection.to_predicate()); </ins> Normalized { value: ty_var, obligations: vec!(obligation)

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
}, "_mm256_sad_epu8" => Intrinsic { inputs: { static INPUTS: [&'static Type; 2] = [&::U8x32, &::U8x32]; &INPUTS }, <del> output: &::U8x32, </del> <ins> output: &::U64x4, </ins> definition: Named("llvm.x86.avx2.psad.bw") }, "_mm256_shuffle_epi8" => Intrinsic {

Discussion:
According to the return type should be but rustc expects a Test case: Compiler error:
cc
I think the has an incorrect return type?
Change:
key.param_env, // Statics (and promoteds inside statics) may access other statics, because unlike consts // they do not have to behave "as if" they were evaluated at runtime. <del> CompileTimeInterpreter::new(tcx.const_eval_limit(), /*can_access_statics:*/ is_static), </del> <ins> CompileTimeInterpreter::new( tcx.const_eval_limit(), /*can_access_statics:*/ is_static, /*check_alignment:*/ tcx.sess.opts.unstable_opts.extra_const_ub_checks, ), </ins> ); let res = ecx.load_mir(cid.instance.def, cid.promoted);

Discussion:
code from rustc this causes a new panic when executed via miri:
Ah, there was a reason why we disabled alignment checks in CTFE... This can probably be reproduced without Miri by passing -Zextra-const-ub-checks to rustc.
Yeah this just need "cargo miri run", no additional flags required. Edit: oops, misread :sweat_smile:
Right, this does also reproduce with . Do you want to move the issue?
Yeah let's move this to the rustc repo.
Change:
// Dorky hack to cause `dump_constraints` to only get called // if debug mode is enabled: <del> debug!("----() End constraint listing {:?}---", self.dump_constraints()); </del> <ins> debug!("----() End constraint listing (subject={}) {:?}---", subject, self.dump_constraints(subject)); </ins> graphviz::maybe_print_constraints_for(self, subject); <ins> let graph = self.construct_graph(); self.expand_givens(&graph); </ins> self.expansion(free_regions, &mut var_data); self.contraction(free_regions, &mut var_data); let values = self.extract_values_and_collect_conflicts(free_regions, <del> &var_data[..], </del> <ins> &var_data, &graph, </ins> errors); self.collect_concrete_region_errors(free_regions, &values, errors); values

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
#include "llvm/Analysis/AliasAnalysis.h" #include "llvm/Analysis/TargetLibraryInfo.h" #include "llvm/Analysis/TargetTransformInfo.h" <ins> #include "llvm/CodeGen/CommandFlags.h" </ins> #include "llvm/CodeGen/TargetSubtargetInfo.h" #include "llvm/IR/AutoUpgrade.h" #include "llvm/IR/AssemblyAnnotationWriter.h"

Discussion:
Please see this StackOverflow <a href=""question</a.
Interesting: rustc -C llvm-args='--list' gives the option list for LLC you might expect llvm-args would be passed to clang (which has the options described in the stack overflow page), and indeed to which these arguments were formerly passed. edit: but it also doesn't seem to be the case recently, as both stable and nightly seem to pass args to llc, not clang.
I think this may actually be a real thing. See . It throws the error: But llc definitely takes this argument. I've traced the argument parsing to . And now that I try it, doesn't seem to work for me either. I'm running . Btw, I ran into this trying to work around .
Added code to print the argv passed to . It prints the args from . So I guess the problem is that llc args != whatever arguments that function expects.
Yes, that appears to be the case. The arguments recognized by and the arguments recognized by the API are different. The Rust compiler uses the LLVM API, so it doesn't recognize certain LLVM options even though they may be valid for . Consider the following: Compile with and execute with . It will print the following: Compare that with the output for (an exercise left to the reader). I need the and for my target, as . I don't know what the solution is here. Is it something for LLVM to solve, or something for rustc to solve?
I'm leaving this open because it's not clear to me how a user should pass arguments directly to llc if they want to; perhaps that's not possible or even something we want. Could you comment on whether we think it's a good idea to allow passing arguments into llc directly? Do we run llc at all? If we don't then it seems that this is not a bug.
Nominating to decide whether we want to expose llc or not (and if we can -- I don't know that we run it directly today). If not, we should close.
I'm moving this to T-dev-tools; it seems like they've put some energy into how to think about the stability of well.
cc this seems like something that would be a tooling/platform team issue if that team existed.

Briefly discussed at the dev-tools meeting: verdict was that this did not seem urgent to address.
Related
Leaving this here in case it's helpful to anyone who comes across this issue: I was able to get what appears to be the full list of the arguments LLVM will accept by way of with: Caution: sharp edges abound.
Exposing these flags would be a matter of using , if we really want to.
Change:
} } <del> fn check_parent_of_field<'cx, 'gcx, 'tcx>(this: &mut MirBorrowckCtxt<'cx, 'gcx, 'tcx>, context: Context, base: &Place<'tcx>, span: Span, flow_state: &Flows<'cx, 'gcx, 'tcx>) { </del> <ins> fn check_parent_of_field<'cx, 'gcx, 'tcx>( this: &mut MirBorrowckCtxt<'cx, 'gcx, 'tcx>, context: Context, base: &Place<'tcx>, span: Span, flow_state: &Flows<'cx, 'gcx, 'tcx>, ) { </ins> // rust-lang/rust#21232: Until Rust allows reads from the // initialized parts of partially initialized structs, we // will, starting with the 2018 edition, reject attempts

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
let compiler = self.compiler; let target = self.target; <ins> let absolute_path = builder.src.join(&relative_path); let redirect_path = absolute_path.join("redirects"); if !absolute_path.exists() || !redirect_path.exists() || dir_is_empty(&absolute_path) || dir_is_empty(&redirect_path) { eprintln!("Please checkout submodule: {}", relative_path.display()); crate::exit!(1); } </ins> // build book builder.ensure(RustbookSrc { target, name: INTERNER.intern_str("book"), <del> src: INTERNER.intern_path(builder.src.join(&relative_path)), </del> <ins> src: INTERNER.intern_path(absolute_path.clone()), </ins> parent: Some(self), });

Discussion:
This might not be a valid request (I have to tell it what to test), but surely it shouldn't just result in such an obscure panic. Cc
you don't have dir ?
it doesn't exists until fetching the submodule
Seems like I don't have that submodule checked out; I don't work on the book so it's not needed (and I keep the checked-out submodules to a minimum to avoid having to update them all the time).
I reproduced it in local, without in and don't update submodule manually, will fail like this.
I can fix it tomorrow, feel free to work on it if you want to fix it earlier.
by the way, do you know why we use those for here?
Not particularly, I am not so familiar with the compiletest code. Probably we panic there so the compiletest runner process can handle(being able to understand compiletest was failed) that.
The fix shouldn't make any changes on the compiletest side. We just need to avoid using submodules(if doesn't exists) instead of assuming that they exist.
Yes, that's another issue, I just met it today.
Change:
<ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #60390, this ICE requires `--emit=mir` flag. fn main() { enum Inner { Member(u32) }; Inner::Member(0); } </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #60390, this ICE requires `--emit=mir` flag. fn main() { enum Inner { Member(u32) }; Inner::Member(0); } </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
/// reach code marked with this function. /// /// The stabilized version of this intrinsic is [`core::hint::unreachable_unchecked`]. <del> #[rustc_const_unstable(feature = "const_unreachable_unchecked", issue = "53188")] </del> <ins> #[rustc_const_stable(feature = "const_unreachable_unchecked", since = "1.57.0")] </ins> pub fn unreachable() -> !; /// Informs the optimizer that a condition is always true.

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
} } <del> type Resolutions<'a> = RefCell<FxHashMap<(Ident, Namespace), &'a RefCell<NameResolution<'a>>>>; </del> <ins> type Resolutions<'a> = RefCell<FxIndexMap<(Ident, Namespace), &'a RefCell<NameResolution<'a>>>>; </ins> /// One node in the tree of modules. pub struct ModuleData<'a> {

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
RawBuckets { raw: self.first_bucket_raw(), hashes_end: unsafe { <del> self.hashes.0.offset(self.capacity as int) </del> <ins> self.hashes.offset(self.capacity as int) </ins> }, marker: marker::ContravariantLifetime, }

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // #42164 #![feature(decl_macro)] #![allow(dead_code)] pub macro m($inner_str:expr) { #[doc = $inner_str] struct S; } macro_rules! define_f { ($name:expr) => { #[export_name = $name] fn f() {} } } fn main() { define_f!(concat!("exported_", "f")); m!(stringify!(foo)); } </ins>

Discussion:
My code is about 500 lines long. I'm running up against an assignment deadline, so I don't have time right now to make a minimal demonstration. But if needed I can do so after Thursday, if someone hasn't gotten to it already. Sorry to dump and run. I normally try to be better about bug reports. :/ I expect this to be related to my copy paste error with repeated if clause: EDIT: Removed code, as there is a minimal example below.
Minimal example: Gives output:
I like to check back in on my issues from time to time to ensure that they haven't become invalid. I found that this issue still exists in the 2017/12/11 nightly ().

The following code ICEs on x8664 linux Suspect that it's this line (expecting that a struct with size 8 has 1 field) ICE message: cc
This isn't fixed, example should have had a or a attribute to make sure that the function is exported.
. CC
These "components" are not exactly struct fields, but rather hardware registers. The alignment padding probably triggers an edge case, I'll have to look deeper.

I found out that doesn't work, so I got a bit creative and tried this (reduced example): Which lead to this: It just prints an error on stable (1.17.0): And of course:
I ran into this with declarative macros on
Panics with the same error on 1.18.0 stable now:
Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax. I think it's odd that a macro can legally expand to invalid syntax...
That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.
I've opened another issue for it:

$ RUST_BACKTRACE=1 rustc $ cat $ rustc --version --verbose
Looks like this was fixed. Output with current nightly as per playground:
Yeah, this was fixed. Marking as E-needstest.