Tom Stellard via llvm-dev
2018-Dec-19 00:12 UTC
[llvm-dev] New LLVM git repository conversion prototype
On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote:> On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote: > > Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" etc. The hyphen indicating that this is a pre-release version coming before "v8.0.0" > > > Here's my proposal: > - Release branches will be named: release/3.5.x (for old version numbering scheme), release/7.x (for new). > - The tags for release branches will be named v8.0.0 (for final), and v8.0.0-rc1 for release candidates. > - Tags on the master branch (which will be created at commits modifying the version file after branch creation, ala r338537) will be named v8.0.0-dev. >There haven't been many more responses in the last few days, so can we try to come to some kind of consensus here? I've skimmed through the most recent replies and there 3 things we need to name: 1. Release tags. There were a lot of small variation on the tag names for releases, but it seems like the preferences was to use the llvm.org prefix, so I'm going to propose using tag names like: llvm.org-8.0.0 llvm.org-8.0.0-rc1 Any strong objections to this? 2. Tags for commits in the master branch that bump the release version. Most of the discussion about this so far has been on what to put after the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). Other things to consider about this tag is that it might be used in a git describe alias to identify commits, so it would be helpful if it was short. One idea I had after reading through all the responses was to use the -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear that you are getting something that isn't an official release. It also is similar to the 8.0.0svn version number that we currently use to indicate a non-released version. Which of these 4 options( dev, base, branchpoint, git) do people prefer? 3. Branch names: It seems like there is some preference to include the minor version number in the release branch, so any strong objections to using release/7.0.x as the branch naming? My last question is what will it take to move forward with the monorepo? Do we just need to settle on the branch names or do we really need to have a decision on all of these? It would be great if we could get the official monorepo up before the end of the year. -Tom> On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <mail at justinbogner.com <mailto:mail at justinbogner.com>> wrote: > > As a bit of a side note, v8.0.0 is probably too brief - I expect v* > could easily match some arbitrary tag that starts with the letter v too > easily. I don't have strong opinions about the particular name, but > something like llvm-8.0.0 or llvm.org-v8.0.0 would be better. > > > I don't feel terribly strongly about whether to use "llvm-8.0.0" or "v8.0.0". > > The "v8.0.0" style seems to be very widely used, so that'd still be my inclination, barring a good reason why we shouldn't. The other scheme I've seen commonly is actually just the raw version, e.g. "8.0.0" without any prefix at all. > > I'll note that there is at least one minor advantage to using one of "v8.0.0" or "8.0.0". Github can make download tarballs/zipfiles from release tags, and when doing so, will name the file "$repository-$name.zip" (if you're downloading a tag or branch), or "$repository-$commithash.zip" otherwise. For tag names, it also strips "v" prefix in front of a version number, if you had one. So, with either of the usual schemes, we'd get an automatically-generated filename of "llvm-8.0.0.zip". Instead of, say, "llvm-llvm-8.0.0.zip" if we were to go with a tag named "llvm-8.0.0". That said -- the LLVM project probably isn't going to use those for our official release distributions, so I think that advantage doesn't really matter. > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Bruce Hoult via llvm-dev
2018-Dec-19 04:01 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Tue, Dec 18, 2018 at 4:13 PM Tom Stellard via llvm-dev < llvm-dev at lists.llvm.org> wrote:> There haven't been many more responses in the last few days, so can we > try to come to some kind of consensus here? >Can we please just get the repo up? I've been waiting two months since it was promised, told bosses I'd have a permanent git repo of llvm up where the hashes were never going to change under people again etc. The remaining discussion seems to be about tags and branch names. Neither of those changes hashes of commits or trees or blobs. Both can be fiddled with after the fact without affecting anything else.> 1. Release tags. There were a lot of small variation on the tag names for > releases, > but it seems like the preferences was to use the llvm.org prefix, > so I'm going to propose using tag names like: > > llvm.org-8.0.0 > llvm.org-8.0.0-rc1 >Fine.> 2. Tags for commits in the master branch that bump the release version. > > Most of the discussion about this so far has been on what to put after > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > Other things to consider about this tag is that it might be used in > a git describe alias to identify commits, so it would be helpful if > it was short. > > One idea I had after reading through all the responses was to use the > -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear > that you are getting something that isn't an official release. It > also is similar to the 8.0.0svn version number that we currently use > to indicate a non-released version. Which of these 4 options( > dev, base, branchpoint, git) do people prefer? >Any. Even keeping 8.0.0svn would make some tools simpler.> 3. Branch names: > > It seems like there is some preference to include the minor version number > in the release branch, so any strong objections to using > release/7.0.x as the branch naming? >Actually, I do object to that. A release branch is something that doesn't get any new features, only bug/security fixes. When you start along the release/7.0 branch you will find tags for 7.0.1, 7.0.2 etc but it remains the 7.0 *branch*. Also: is that .0 *ever* again going to be incremented? Not as far as I know. It probably should have been dropped at release/4 Also: I haven't seen anyone bike-shedding whether the tags should be annotated tags or lightweight tags. I don't think that's because everyone knows the difference and implicitly agrees on the answer :-) :-) The answer (in any public repo, really) should be annotated tags, so they include the committer name and the date. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181218/95f25551/attachment.html>
Tom Stellard via llvm-dev
2018-Dec-19 05:28 UTC
[llvm-dev] New LLVM git repository conversion prototype
On 12/18/2018 08:01 PM, Bruce Hoult wrote:> On Tue, Dec 18, 2018 at 4:13 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > There haven't been many more responses in the last few days, so can we > try to come to some kind of consensus here? > > > Can we please just get the repo up? I've been waiting two months since it was promised, told bosses I'd have a permanent git repo of llvm up where the hashes were never going to change under people again etc. > > The remaining discussion seems to be about tags and branch names. Neither of those changes hashes of commits or trees or blobs. Both can be fiddled with after the fact without affecting anything else. >Yes, I agree with you that we need to move forward. I think enough people have given input that I'm personally fine if James just wants to make a final decision based on the responses so far.> > 1. Release tags. There were a lot of small variation on the tag names for releases, > but it seems like the preferences was to use the llvm.org <http://llvm.org> prefix, > so I'm going to propose using tag names like: > > llvm.org-8.0.0 > llvm.org-8.0.0-rc1 > > > Fine. > > > 2. Tags for commits in the master branch that bump the release version. > > Most of the discussion about this so far has been on what to put after > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > Other things to consider about this tag is that it might be used in > a git describe alias to identify commits, so it would be helpful if > it was short. > > One idea I had after reading through all the responses was to use the > -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear > that you are getting something that isn't an official release. It > also is similar to the 8.0.0svn version number that we currently use > to indicate a non-released version. Which of these 4 options( > dev, base, branchpoint, git) do people prefer? > > > Any. Even keeping 8.0.0svn would make some tools simpler. > > > > 3. Branch names: > > It seems like there is some preference to include the minor version number > in the release branch, so any strong objections to using > release/7.0.x as the branch naming? > > > Actually, I do object to that. > > A release branch is something that doesn't get any new features, only bug/security fixes. When you start along the release/7.0 branch you will find tags for 7.0.1, 7.0.2 etc but it remains the 7.0 *branch*. >Are you suggesting release/7.0 instead of release/7.0.x? If so, I agree.> Also: is that .0 *ever* again going to be incremented? Not as far as I know. It probably should have been dropped at release/4 >I am planning to do a 7.1.0 release due to a bug fix that breaks the ABI. -Tom> Also: I haven't seen anyone bike-shedding whether the tags should be annotated tags or lightweight tags. I don't think that's because everyone knows the difference and implicitly agrees on the answer :-) :-) > > The answer (in any public repo, really) should be annotated tags, so they include the committer name and the date. >
Hans Wennborg via llvm-dev
2018-Dec-19 09:20 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Wed, Dec 19, 2018 at 1:12 AM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote: > > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote: > > > > Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" etc. The hyphen indicating that this is a pre-release version coming before "v8.0.0" > > > > > > Here's my proposal: > > - Release branches will be named: release/3.5.x (for old version numbering scheme), release/7.x (for new). > > - The tags for release branches will be named v8.0.0 (for final), and v8.0.0-rc1 for release candidates. > > - Tags on the master branch (which will be created at commits modifying the version file after branch creation, ala r338537) will be named v8.0.0-dev. > > > > There haven't been many more responses in the last few days, so can we > try to come to some kind of consensus here? > > I've skimmed through the most recent replies and there 3 things we need to > name: > > 1. Release tags. There were a lot of small variation on the tag names for releases, > but it seems like the preferences was to use the llvm.org prefix, > so I'm going to propose using tag names like: > > llvm.org-8.0.0 > llvm.org-8.0.0-rc1 > > Any strong objections to this?Maybe llvm.org-8.0.0-final for the final one, similar to what we do currently? Otherwise sgtm.> 2. Tags for commits in the master branch that bump the release version.I may have missed something in the thread, but do we actually *need* this?> Most of the discussion about this so far has been on what to put after > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > Other things to consider about this tag is that it might be used in > a git describe alias to identify commits, so it would be helpful if > it was short. > > One idea I had after reading through all the responses was to use the > -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear > that you are getting something that isn't an official release. It > also is similar to the 8.0.0svn version number that we currently use > to indicate a non-released version. Which of these 4 options( > dev, base, branchpoint, git) do people prefer?I think it's important that a tag actually describes what the commit is. "v8.0.0-dev" or "-git" sounds like it's the development version of 8.0.0, which it's not -- as proposed, it's really the first commit after 7.0.0 was branched. If we really need a tag for this, and I'm not sure we do, I think we should instead tag the commit that we branch from, i.e. v7.0.0-branchpoint. If brevity is important, it could be just "v7-bp". I propose that we don't block on having these.> 3. Branch names: > > It seems like there is some preference to include the minor version number > in the release branch, so any strong objections to using > release/7.0.x as the branch naming?That sgtm. Thanks, Hans> > On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <mail at justinbogner.com <mailto:mail at justinbogner.com>> wrote: > > > > As a bit of a side note, v8.0.0 is probably too brief - I expect v* > > could easily match some arbitrary tag that starts with the letter v too > > easily. I don't have strong opinions about the particular name, but > > something like llvm-8.0.0 or llvm.org-v8.0.0 would be better. > > > > > > I don't feel terribly strongly about whether to use "llvm-8.0.0" or "v8.0.0". > > > > The "v8.0.0" style seems to be very widely used, so that'd still be my inclination, barring a good reason why we shouldn't. The other scheme I've seen commonly is actually just the raw version, e.g. "8.0.0" without any prefix at all. > > > > I'll note that there is at least one minor advantage to using one of "v8.0.0" or "8.0.0". Github can make download tarballs/zipfiles from release tags, and when doing so, will name the file "$repository-$name.zip" (if you're downloading a tag or branch), or "$repository-$commithash.zip" otherwise. For tag names, it also strips "v" prefix in front of a version number, if you had one. So, with either of the usual schemes, we'd get an automatically-generated filename of "llvm-8.0.0.zip". Instead of, say, "llvm-llvm-8.0.0.zip" if we were to go with a tag named "llvm-8.0.0". That said -- the LLVM project probably isn't going to use those for our official release distributions, so I think that advantage doesn't really matter. > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Bruce Hoult via llvm-dev
2018-Dec-19 09:43 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Wed, Dec 19, 2018 at 1:21 AM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote:> If we really need a tag for this, and I'm not sure we do, I think we > should instead tag the commit that we branch from, i.e. > v7.0.0-branchpoint. If brevity is important, it could be just "v7-bp". >You don't really need it. "git merge-base release/7.0 master" will find it, possibly with the "--fork-point" flag as well for the paranoid (in case there was a merge joining them later .. there shouldn't be)> I propose that we don't block on having these. >All tags can be added or adjusted later, at leisure. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181219/22425641/attachment.html>
David Greene via llvm-dev
2018-Dec-19 18:20 UTC
[llvm-dev] New LLVM git repository conversion prototype
[ Consider all of this to be preferences, not anything close to an objection. ] Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes:> There haven't been many more responses in the last few days, so can we > try to come to some kind of consensus here?I agree with others that this discussion doesn't have to delay the official repo from being posted. Let's get that done ASAP. Lots of people are waiting on it.> 1. Release tags. There were a lot of small variation on the tag names for releases, > but it seems like the preferences was to use the llvm.org prefix, > so I'm going to propose using tag names like: > > llvm.org-8.0.0 > llvm.org-8.0.0-rc1 > > Any strong objections to this?SGTM. I don't think we need a -final suffix or anything. A straight version number seems to convey intent for many other projects. But not a big deal either way. We almost certainly want annotated tags.> 2. Tags for commits in the master branch that bump the release version. > > Most of the discussion about this so far has been on what to put after > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > Other things to consider about this tag is that it might be used in > a git describe alias to identify commits, so it would be helpful if > it was short. > > One idea I had after reading through all the responses was to use the > -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear > that you are getting something that isn't an official release. It > also is similar to the 8.0.0svn version number that we currently use > to indicate a non-released version. Which of these 4 options( > dev, base, branchpoint, git) do people prefer?I agree that -git or -dev could be misleading. I also agree that we may not need this tag at all. If we want the tag, I thirdly agree that tagging the split point is more useful/convenient than tagging the version bump. I have a preference for an llvm.org prefix on this tag, just like for the release tags, for the same reason we have it there: namespacing to avoid downstream conflicts. But it's certainly not a dealbreaker. -David
David Jones via llvm-dev
2018-Dec-19 19:05 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev < llvm-dev at lists.llvm.org wrote:> [ Consider all of this to be preferences, not anything close to an > objection. ] > > Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > There haven't been many more responses in the last few days, so can we > > try to come to some kind of consensus here? > > I agree with others that this discussion doesn't have to delay the > official repo from being posted. Let's get that done ASAP. Lots of > people are waiting on it. > > > 1. Release tags. There were a lot of small variation on the tag names > for releases, > > but it seems like the preferences was to use the llvm.org prefix, > > so I'm going to propose using tag names like: > > > > llvm.org-8.0.0 > > llvm.org-8.0.0-rc1 > > > > Any strong objections to this? > > SGTM. I don't think we need a -final suffix or anything. A straight > version number seems to convey intent for many other projects. But not > a big deal either way. > > We almost certainly want annotated tags. > > > 2. Tags for commits in the master branch that bump the release version. > > > > Most of the discussion about this so far has been on what to put after > > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > > Other things to consider about this tag is that it might be used in > > a git describe alias to identify commits, so it would be helpful if > > it was short. > > > > One idea I had after reading through all the responses was to use the > > -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear > > that you are getting something that isn't an official release. It > > also is similar to the 8.0.0svn version number that we currently use > > to indicate a non-released version. Which of these 4 options( > > dev, base, branchpoint, git) do people prefer? >Of these, -git seems the least misleading, based on responses so far (branchpoint in particular). However, based on previous comments, I'm not sure we want the specific format you suggested (see previous; it's missing at least an llvm prefix namespace).> I agree that -git or -dev could be misleading. I also agree that we may > not need this tag at all.Strictly speaking, we don't *need* to switch to git, either. ;-) It's worth our time collectively (I claim) to get it right from the beginning; a broken or wrong output from a built-in git command seems problematic. If we want the tag, I thirdly agree that> tagging the split point is more useful/convenient than tagging the > version bump. >Tagging the split point is semantically the wrong thing, though: if you `git describe` the last commit before the branch for release ${N} (i.e., the last commit of N), the descriptor will be ${N+1} (or whatever tag was applied). The version bump commit will then be "${N+1}-1", meaning the second commit of the N+1 release (with commit hashes as appropriate). That's an off-by-one error in several ways. ;-) Also note, the split point is trivial to reach from the version bump, but not vice versa. It's reachable as ^ from the version bump tag, and also (less trivially, but still without explicit set arithmetic) as merge-base. An easy way to reason about this is that the version bump tag should only be reachable from the release branch for that version. So if the 8.0 bump is reachable from the 7.x release branch, that's going to result in `git describe` attributing commits with the wrong version.> I have a preference for an llvm.org prefix on this tag, just like for > the release tags, for the same reason we have it there: namespacing to > avoid downstream conflicts. But it's certainly not a dealbreaker. > > -David > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181219/4bc5be64/attachment.html>
Mehdi AMINI via llvm-dev
2018-Dec-19 19:25 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Wed, Dec 19, 2018 at 1:21 AM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Dec 19, 2018 at 1:12 AM Tom Stellard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote: > > > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman < > Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote: > > > > > > Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" > etc. The hyphen indicating that this is a pre-release version coming before > "v8.0.0" > > > > > > > > > Here's my proposal: > > > - Release branches will be named: release/3.5.x (for old version > numbering scheme), release/7.x (for new). > > > - The tags for release branches will be named v8.0.0 (for final), and > v8.0.0-rc1 for release candidates. > > > - Tags on the master branch (which will be created at commits > modifying the version file after branch creation, ala r338537) will be > named v8.0.0-dev. > > > > > > > There haven't been many more responses in the last few days, so can we > > try to come to some kind of consensus here? > > > > I've skimmed through the most recent replies and there 3 things we need > to > > name: > > > > 1. Release tags. There were a lot of small variation on the tag names > for releases, > > but it seems like the preferences was to use the llvm.org prefix, > > so I'm going to propose using tag names like: > > > > llvm.org-8.0.0 > > llvm.org-8.0.0-rc1 > > > > Any strong objections to this? > > Maybe llvm.org-8.0.0-final for the final one, similar to what we do > currently? Otherwise sgtm. > > > 2. Tags for commits in the master branch that bump the release version. > > I may have missed something in the thread, but do we actually *need* this? >That enables `git describe` to return the right version name while in master (and indicates the number of commits since the branching point) See David's email here: http://lists.llvm.org/pipermail/llvm-dev/2018-November/127822.html -- Mehdi> > > Most of the discussion about this so far has been on what to put after > > the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint). > > Other things to consider about this tag is that it might be used in > > a git describe alias to identify commits, so it would be helpful if > > it was short. > > > > One idea I had after reading through all the responses was to use the > > -git suffix on the tags. e.g. v8.0.0-git. It's short and it's clear > > that you are getting something that isn't an official release. It > > also is similar to the 8.0.0svn version number that we currently use > > to indicate a non-released version. Which of these 4 options( > > dev, base, branchpoint, git) do people prefer? > > I think it's important that a tag actually describes what the commit > is. "v8.0.0-dev" or "-git" sounds like it's the development version of > 8.0.0, which it's not -- as proposed, it's really the first commit > after 7.0.0 was branched. > > If we really need a tag for this, and I'm not sure we do, I think we > should instead tag the commit that we branch from, i.e. > v7.0.0-branchpoint. If brevity is important, it could be just "v7-bp". > > I propose that we don't block on having these. > > > > 3. Branch names: > > > > It seems like there is some preference to include the minor version > number > > in the release branch, so any strong objections to using > > release/7.0.x as the branch naming? > > That sgtm. > > Thanks, > Hans > > > > > > > On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <mail at justinbogner.com > <mailto:mail at justinbogner.com>> wrote: > > > > > > As a bit of a side note, v8.0.0 is probably too brief - I expect v* > > > could easily match some arbitrary tag that starts with the letter > v too > > > easily. I don't have strong opinions about the particular name, but > > > something like llvm-8.0.0 or llvm.org-v8.0.0 would be better. > > > > > > > > > I don't feel terribly strongly about whether to use "llvm-8.0.0" or > "v8.0.0". > > > > > > The "v8.0.0" style seems to be very widely used, so that'd still be my > inclination, barring a good reason why we shouldn't. The other scheme I've > seen commonly is actually just the raw version, e.g. "8.0.0" without any > prefix at all. > > > > > > I'll note that there is at least one minor advantage to using one of > "v8.0.0" or "8.0.0". Github can make download tarballs/zipfiles from > release tags, and when doing so, will name the file "$repository-$name.zip" > (if you're downloading a tag or branch), or "$repository-$commithash.zip" > otherwise. For tag names, it also strips "v" prefix in front of a version > number, if you had one. So, with either of the usual schemes, we'd get an > automatically-generated filename of "llvm-8.0.0.zip". Instead of, say, > "llvm-llvm-8.0.0.zip" if we were to go with a tag named "llvm-8.0.0". That > said -- the LLVM project probably isn't going to use those for our official > release distributions, so I think that advantage doesn't really matter. > > > > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181219/317a5095/attachment.html>